On Saturday 27 March 2004 06:41, Andrew Pam wrote: > On Sat, Mar 27, 2004 at 04:20:44AM -0000, James Craig Burley wrote: > > >No. That's one less port he can use to connect to you (on any given > > >destination port). He can still use the same source port to connect to > > >others. TCP connections are four-tuples. > > > > Should I not trust O'Reilly's "TCP/IP Network Administration", by > > Craig Hunt, Second Edition, page 46, where it says, among other things > > consistent with this, > > > > It is the pair of port numbers, source and destination, that > > uniquely identifies each network connection. > > > > or do you think it is just simplifying things for the benefit of its > > audience? > > Read that again. The pair of port numbers, source and destination > (at the TCP layer)... plus the pair of IP addresses (at the IP layer).
I think there's a mixup between what you two are talking about - on a given _network_ then yes, you need the 4-tuple to identify a single connection (that is port X on IP address Y talking to port A on IP address B is not the same connection as port X on IP address B talking to port Y on IP address A etc) - but that doesn't mean that a TCP stack for _client_ sockets re-uses socket numbers for different connections - each client socket on a given host (meaning a network interface) has a number unique to that host: Stevens, vol 1, page 42 "[...] the client just needs to be certain that the ephemeral port is unique on the client host. The TCP and UDP codes guarantee this uniqueness." page 43: "The _socket_pair_ for a TCP connection is the 4-tuple that defines the two endpoints of the connection [...]. A socket pair uniquely identifies every TCP connection on an internet. The two values that identify each endpoint, an IP address and a port number, are often called a socket." page 45 (discussing a client connecting twice to the same server socket: "The TCP code on the client host assigns the new socket an unused ephemeral port number [...]." [The O'Reilly books are good, but for authoritative TCP/IP always go to Stevens or the source code] In particular, a client can open two different sockets to the listening socket on a single host (eg web browser opens 2 connections to port 80 on the same host), and so the 4-tuple shows 2 connections differentiated only by the client socket number, but the _client_ socket numbers are always unique even when speaking to different hosts. The stack for the server socket (the one that called listen()) de-multiplexes input packets based on the client IP+port and hands it off to the appropriate file descriptor returned by accept(), but there is no de-multiplexing on the client side - and I'm pretty sure it would break a huge amount of existing code if anyone wrote a TCP stack that did so (which I suppose it could do, given that the client socket number isn't actually assigned until the connect() call returns). > Many systems will use originating port numbers in sequence; more recently, > for security reasons, they may use them in random order. However the > fact remains that TCP/IP connections are uniquely identified by the > four-tuple [source IP, source port, dest IP, dest port]. The limitation > on the number of open connections is therefore generally available RAM > for the networking structures in the OS kernel (or application, in the > case of an application crafting its own packets.) Amusingly there was originally an upper limit of 5,000 in the BSD socket code, but this was a typo that was intended even then to be 50,000. Anyway, bringing it all vaguely back on topic, the point of the tarpit is not so much as to tie up the resources for an inactive socket, but to chew up the limited upstream bandwidth of trojan DSPAM clients on asymmetric connections, and where those trojans have been written simply to stay small and unobtrusive (to evade discovery) then it's quite likely that they will limit the number of sockets they use simultaneously. Cheers -- Tim
