Re: [PLUG] udp ports

[Rich Freeman <r-plug@thefreemanclan.net>]

On Sat, May 3, 2014 at 9:15 PM, Sam Gleske <sam.mxracer@gmail.com> wrote:
> On Sat, May 3, 2014 at 4:19 PM, Rich Freeman <r-plug@thefreemanclan.net>
> wrote:
>> I agree that you're limited by the combination of ports on the client
>> and server, but that means 64k^2 "connections" PER IP, or a total of
>> 64k^2*2^32 connections if you have the maximum number of "connections"
>> open with every single host on the internet.
>>
>
> You're right if you're talking about per interface.  e.g if a computer has
> two interfaces they each have 65k ports available (not squared).  You're
> right about a multiple clients connecting to the same serving port if
> there's a listener.  From the server's perspective if it is connecting as a
> client it would need to use one of the 65k ports available to receive
> communication.  So your math is a little off.  Each IP only.  Whether your
> server is sending communication or receiving communication it only has one
> of the 65k ports available to it for communication.

I'm talking about a single interface.

Suppose I have two computers, with IPs 1.1.1.1 and 1.1.1.2.  Using the
notation IP:port I can send a packet from 1.1.1.1:1 to 1.1.1.2:1, and
I can send a packet from 1.1.1.1:2 to 1.1.1.2:1, and both computers
can handle that situation just fine.  I can also send packets from
1.1.1.1:1 to 1.1.1.3:1 at the same time.  1.1.1.3:1 can send a packet
to 1.1.1.2:1 at the same time as well.  So, 1.1.1.2 is now receiving
packets from 3 different sources, all on a single port.

Packets from 1.1.1.1:1 can go to any port on 1.1.1.2.  Any port on
1.1.1.1 can send a packet to 1.1.1.2:1.  So, between the two computers
you can have 64k^2 simultaneous packets in flight and every one will
get to the right place.

The only bit I'm unsure of is whether Linux will let a program send
packets from 1.1.1.1:1 to 1.1.1.2.:1 and 1.1.1.3:1 at the same time,
or if it will force the program to use two different source ports.  I
don't think that is the case.

>
>>
>> The term "connection" is a bit inaccurate though, as there is no
>> actual connection.  An application can bind to a port and accept udp
>> packets, and an application can send packets from a port (though as
>> far as I'm aware, doing so does not in any way reserve the port if it
>> is transmit-only - so 14 different applications could all send packets
>> from a particular UDP port).  When packets are received they contain
>> the source IP and port, so an application can keep track of up to 64k
>> different streams of packets from any particular IP.
>
>
> I don't think that's accurate.  If you review netstat or lsof when you're
> using your browser to connect to a website or stream you'll notice that for
> each persistent connection to the website has an arbitrarily high port to
> receive data from the server it has requested.

On the server side all the connections will be to port 80.  On the
client side each outgoing connection will use a random IP -
non-privileged clients can't bind low ports anyway.

However, nothing prevents two clients from using the same port for an
outgoing connection as long as they're to different destination IP and
ports.

For example, look at this netstat output:
tcp        0      0 localhost:12345         localhost:http          ESTABLISHED
tcp        0      0 localhost:12345         localhost:smtp          ESTABLISHED

I just ran two instances of netcat specifying the local port.

>
> You're correct many clients can connect to the same serving port.  But that
> serving port is still one of the 65k on that server.  When the server
> responds to those services it is using that same listening port to respond
> to communication.  Ports can be used to send and receive established and
> related data.

Well, with UDP there is no requirement that return packets use the
same port, though I imagine it usually happens that way.

>
> As a summary, listeners take up one port.  Multiple clients can connect to
> that port and the server uses that listening port to respond to client
> requests.  When the server connects to other servers that have listening
> ports (e.g. you use wget on the server to get a file) then your wget client
> will select an arbitrarily high port from the 65k available ports in which
> it will recieve communication.  Overall, each computer only has 65k ports
> per interface whether you are sending communication or receiving
> communication.  That has always been.

I agree that there are 64k ports per interface.  However, using those
64k ports you can support far more than 64k connections.  As I
demonstrated with my netcat example above using only one local port I
could make two connections.  As you pointed out a server handles many
incoming connection on the same local port.

Rich
___________________________________________________________________________
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