Sam Gleske on 3 May 2014 18:22:50 -0700

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] udp ports

On Sat, May 3, 2014 at 4:19 PM, Rich Freeman <> 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.
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.  No matter if communication happens over TCP or UDP.  The application creates a socket, the network stack receives communication, demultiplexes the port and sends the data to the socket for the application.  It still needs to take up a port for that.  It's just how it works.  Most of these connections are very short lived.  TCP and UDP are RFC's so the implementation will have the same bahavior as it does in any other OS.  The networking will behave the same as far as port multiplexing is concerned.

Now, I'm not sure if the linux implementation of UDP falls short of
this ideal, or if I'm missing something subtle.  However, it is just
fine for 75 different computers to all send packets to your DNS server
at the same time, and this only consumes one port on your DNS server.
Even with TCP you can have 75 incoming connections to port 80 on your
webserver from different hosts at the same time.  What you can't have
is 75 different TCP connections from the same source port on one host
to the same destination port on your local host.  For UDP that
limitation doesn't necessarily exist, since it is stateless.

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.

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.

Philadelphia Linux Users Group         --
Announcements -
General Discussion  --