| brent timothy saner on 3 May 2014 20:02:01 -0700 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
| Re: [PLUG] udp ports |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/03/2014 09:55 PM, Rich Freeman wrote: > On Sat, May 3, 2014 at 9:50 PM, brent saner <brent.saner@gmail.com> > wrote: >> >> http://www.wikipedia.org/wiki/Multicast >> > > Multicast is a bit different. With multicast (including the > specific case of broadcast) my computer sends a single packet, and > it goes to many other computers, with routers replicating traffic > at each point along the way as needed. > > With unicast my computer has to send the same packet once for each > destination it is intended for. You can still do that using a > single source port for every computer on the internet, and even > 64k destination ports on each of those. It wouldn't make the > network admins too happy though, assuming the NIC didn't melt. > > Rich I should have clarified. Multicast UDP really should be used if you expect a large number of connections on one destination, especially with the lack of congestion control inherent in UDP. With multicast implementations, you use one egress (source). I mean, this is all assuming you're writing the software. Straight UDP unicast RFC (RFC5405), however, DOES state: ______________________ UDP datagrams may be directly sent and received, without any connection setup. *Using the sockets API, applications can receive packets from more than one IP source address on a single UDP socket. [Some servers use this to exchange data with more than one remote host through a single UDP socket at the same time.]* Many applications need to ensure that they receive packets from a particular source address; these applications MUST implement corresponding checks at the application layer or explicitly request that the operating system filter the received packets. ______________________ (section 3.6, p16, 3rd paragraph. emphasis added.) Further to note, RFC768's 'Format' and 'Fields' sections clearly dictate that each datagram (optionally in IPv4 and required in IPv6) include the source IP, **the source port**, the destination IP, and the destination port. Since this is specified *per datagram*, you can use multiple process on the same egress ephemeral port. Of course, this is assuming that the datagrams on the same ephemeral port are going to *different destinations*. If not, you're going to see some potentially very strange things happening. (I would presume it'd either look a lot like total dropped traffic for one application using that port *or* mixed data going to one application and the other half to the other- depending on how the UDP/IP stack prioritizes those packets in the kernel. i.e. if they're balanced or if it's all given to the lowest PID or what have you). However, because I'm thorough to an annoying level, I tested this out myself. (nc = OpenBSD netcat version, not the GNU version, in case the switches look wonky) 1.) on host "A": $ nc -l -u 32780 2.) on host "B": $ nc -u -p 32790 <HOST A IPADDR> 32780 3.) ALSO on host "B", using the same egress/source port: $ nc -u -p 32790 <HOST A IPADDR> 32780 4.) And a netstat on host "B" confirms the same "ephemeral" (philosophical question- is it still ephemeral if within the ephemeral range but manually specified? hehe) ports used by *different processes*: udp 0 0 <HOST B IPADDR1>:32790 <HOST A IPADDR>:32780 ESTABLISHED 3422/nc udp 0 0 <HOST B IPADDR1>:32790 <HOST A IPADDR>:32780 ESTABLISHED 3312/nc Ta-da. So all this to say no, you aren't running out of source ports if we're talking strictly UDP. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTZa2hAAoJEIwATC+TSB9rYyEP/0+/o+e6tZUnHSqE3Zuaxlav gCBBvsNCBVHlwMiHF7S3UAwXEyEo+QTPI/4HGVSZdzn9Sgerm2E1kp2L2a74Chfr klvKNbjGMDNPCVbmUD2U5a8Qzw/MrclQ2DkNPhRkO5dcQR/blLq8ShPsx5TsZbcO RFqn5tdTcryHQvtwFdD72/61i5pVpGofTM4qH3nSnjHip//b7iSEAYOxjx3rUPZG F5H2JIiSrcWkHFFPVfqSSsd6z8S92M7Z/DXMLrZKNb+E+QXpO3P7gd6JuIBT3AYc 9aFIEjgbukBSzTZnF/4FV9FfPAbfFut7+3CaREAQVi8H9+Tw97rmc4RVrSuELtO1 VclIOo29Pa3N8hGda2pVMdBLXWs6Rz+esXnfwG/3CwP8c5V48Jatt6ZbQaunKPG6 ESbZC3K635ZkCuarfYOh0YX2veF8GU7x99xHGUQFe65fjWuH1WMZB1pMSlhPJSrJ Yz/fOY1/hpj9VTWvzNih67Cc8/oy+DkRZQHeiqsjC8prLtc421jhUa1erYp4LW/w AGCsdI9/JO0iSYIG7mgI4c3EAXps6b0mJmWAzo/fywzaPU2x1+AjPzUbt6I1QbJR CFnztFm1XeSWfFDBiq8sZSQTJKnW+HSPGjCrqXU6Vn/dNCoCITbLpx4l+XBBLCDb W1Jhojo1wRf6yJW+MGhe =WIan -----END PGP SIGNATURE----- ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug