~ubuntu-branches/ubuntu/vivid/nodejs/vivid

                      "textRaw": "`port` Integer. Destination port. ",

                      "desc": "Integer. Destination port."

                      "textRaw": "`address` String. Destination hostname or IP address. ",

                      "desc": "String. Destination hostname or IP address."

                      "textRaw": "`callback` Function. Called when the message has been sent. Optional. ",

                      "desc": "Function. Called when the message has been sent. Optional.",

              "desc": "<p>For UDP sockets, the destination port and address must be specified.  A string\nmay be supplied for the <code>address</code> parameter, and it will be resolved with DNS.\n\n</p>\n<p>If the address is omitted or is an empty string, <code>&#39;0.0.0.0&#39;</code> or <code>&#39;::0&#39;</code> is used\ninstead.  Depending on the network configuration, those defaults may or may not\nwork; it&#39;s best to be explicit about the destination address.\n\n</p>\n<p>If the socket has not been previously bound with a call to <code>bind</code>, it gets\nassigned a random port number and is bound to the &quot;all interfaces&quot; address\n(<code>&#39;0.0.0.0&#39;</code> for <code>udp4</code> sockets, <code>&#39;::0&#39;</code> for <code>udp6</code> sockets.)\n\n</p>\n<p>An optional callback may be specified to detect DNS errors or for determining\nwhen it&#39;s safe to reuse the <code>buf</code> object.  Note that DNS lookups delay the time\nto send for at least one tick.  The only way to know for sure that the datagram\nhas been sent is by using a callback.\n\n</p>\n<p>Example of sending a UDP packet to a random port on <code>localhost</code>;\n\n</p>\n<pre><code>var dgram = require(&#39;dgram&#39;);\nvar message = new Buffer(&quot;Some bytes&quot;);\nvar client = dgram.createSocket(&quot;udp4&quot;);\nclient.send(message, 0, message.length, 41234, &quot;localhost&quot;, function(err, bytes) {\n  client.close();\n});</code></pre>\n<p><strong>A Note about UDP datagram size</strong>\n\n</p>\n<p>The maximum size of an <code>IPv4/v6</code> datagram depends on the <code>MTU</code> (<em>Maximum Transmission Unit</em>)\nand on the <code>Payload Length</code> field size.\n\n</p>\n<ul>\n<li><p>The <code>Payload Length</code> field is <code>16 bits</code> wide, which means that a normal payload\ncannot be larger than 64K octets including internet header and data\n(65,507 bytes = 65,535 − 8 bytes UDP header − 20 bytes IP header);\nthis is generally true for loopback interfaces, but such long datagrams\nare impractical for most hosts and networks.</p>\n</li>\n<li><p>The <code>MTU</code> is the largest size a given link layer technology can support for datagrams.\nFor any link, <code>IPv4</code> mandates a minimum <code>MTU</code> of <code>68</code> octets, while the recommended <code>MTU</code>\nfor IPv4 is <code>576</code> (typically recommended as the <code>MTU</code> for dial-up type applications),\nwhether they arrive whole or in fragments.</p>\n<p>For <code>IPv6</code>, the minimum <code>MTU</code> is <code>1280</code> octets, however, the mandatory minimum\nfragment reassembly buffer size is <code>1500</code> octets.\nThe value of <code>68</code> octets is very small, since most current link layer technologies have\na minimum <code>MTU</code> of <code>1500</code> (like Ethernet).</p>\n</li>\n</ul>\n<p>Note that it&#39;s impossible to know in advance the MTU of each link through which\na packet might travel, and that generally sending a datagram greater than\nthe (receiver) <code>MTU</code> won&#39;t work (the packet gets silently dropped, without\ninforming the source that the data did not reach its intended recipient).\n\n</p>\n"