Re: Definition of a socket on Sun's website

lewmania942@xxxxxxxx wrote: 
Hi,

there's an original definition of a socket at the following URL:

http://java.sun.com/docs/books/tutorial/networking/sockets/definition.html

The page is called "What is a Socket?" and the description is not long.

The author states that:


If everything goes well, the server accepts the connection. Upon
acceptance, the server gets a new socket bound to a different port.
It needs a new socket (and consequently a different port number) so
that it can continue to listen to the original socket for connection
requests while tending to the needs of the connected client.



I don't understand that. Moreover, there's a drawing where, upon
acceptance of a new connection, the *server* is using a new port.


Im not surprised. It's complete bollocks. I wrote to Sun years ago pointing out that they were wrong, but they didn't bother to answer. I don't know why they have a "feedback" link at all.

I always thought that a TCP connection was uniquely identified by a
*pair* of sockets (server:port and client:port) and that a "server"
socket could be simultaneously used in several connections (and I
double checked by reading the RFCs).


And you were right.

That page got me so confused that I decided to do some testing.

So I did a test here on my local network.  I set up Tomcat on one
machine, and configured the stateful firewall of this machine to
drop *every* packets but the ones coming from another machine
destined to the port 8080 and the ones leaving port 8080 and going
to another machine.  So the server, for that simple test, wasn't
even allowed to talk to himself (ie no traffic allowed on 127.0.0.1).

I really wanted to be sure that no other port than 8080 was used
on the server.

And sure enough I could connect from several other machines to the
server... Using only port 8080 on the server.


Good work. Can I recommend ethereal? It's an excellent open source protocol analyser, and I think you would find it very interesting and educational. It will also re-confirm your results above.

Now I'm puzzled and I've got several questions for the
gurus out there...

1. Isn't the following phrase simply plain wrong:


It needs a new socket (and consequently a different port number)
so that it can continue to listen to the original socket for
connection requests while tending to the needs of the connected
client.

Its not just wrong. It is also very misleading and wastes many people's time.

2. Is there a theorical limit of how many simultaneous TCP
connections a single server (no load-balancing) can handle
on a single socket?  For example, could a web server accepts
100.000 simultaneous connections on port 80, from 100.000
different clients (and hence having 100.000 different
"single server socket" <--> socket pairs identifying
100.000 connections) ?  (given it has enough bandwith/processing
power, etc.)

Yes. By my reckoning, one other machine can maintain 65535 connections (avoid port 0), and there are almost 2^32 other IP addresses, giving a theoretical nearly 2^48 connections. With IPv6 it's an alltogether bigger number. 

3. In one thread posted on cljh a few months ago, called "Socket woes",
someone said:


After a socket is closed the port number remains unavailable
for a time (four minutes "by statute," IIRC, although it's
fairly common for Web servers to use shorter intervals); this
is to allow time for stale packets to expire from the network.
(You wouldn't want a packet that had been temporarily trapped
in a routing loop to escape and disrupt a new unrelated
connection that happened to use the same port number ...)



The message can be found here:

http://groups-beta.google.com/group/comp.lang.java.help/msg/a74f1800615b9b6f?dmode=source

Does a web server prevent a client from reconnecting from the exact
same IP, with the exact same (client) port number before some
time interval?  Or is this precaution taken on the client's side?

I have a feeling that both ends are required to implement this hold-down, but I'm not certain. Consult the RFC.


Could really some hypothetical "stale packets" (in case the same
client, on the same IP, using the same "client socket") disrupt
an HTTP connection?  Doesn't "HTTP over TCP over IP" prevent this?
(I mean, wouldn't those "stale packets" simply be discarded?)

Yes. If a stale packet disrupted the TCP connection, that connection will then get reset, effectively slamming the phone down. Certain denial of service attacks work by sending such packets. Of course, a smart application could simply reconnect and carry on.

Steve
.

Relevant Pages

  • Re: Still cant connect to RWW or OWA remotely
    ... it certainly appears to be something about the SBS configuration. ... Meridian.local Ethernet adapter Local Area Connection: ... Windows SMALL BUSINESS SERVER 2003 Windows IP Configuration ... 192.168.254.254) directly to a port on the router and then ...
    (microsoft.public.windows.server.sbs)
  • Re: Still cant connect to RWW or OWA remotely
    ... it certainly appears to be something about the SBS configuration. ... Meridian.local Ethernet adapter Local Area Connection: ... Windows SMALL BUSINESS SERVER 2003 Windows IP Configuration ... 192.168.254.254) directly to a port on the router and then ...
    (microsoft.public.windows.server.sbs)
  • RE: VBscript Error on SBS2k3
    ... DHCP Server turned of SonicWALL with VPN Pass through request for IP to ... the problem should be caused by the 4125 port. ... > | Accessories and Communications and Remote Desktop Connection? ... > | 2.In Internet Explorer on the workstation you are connecting from, ...
    (microsoft.public.windows.server.sbs)
  • Re: Socket Exception
    ... In this case the server most likely rejected your ... connection. ... Each command is a new socket connection that is opened and closed ... /// Required designer variable. ...
    (microsoft.public.win32.programmer.networks)
  • Re: interfaces lo:1 lo:2 lo:3? (for remote ssh tunnels)
    ... That's the problem tunneling (port forwarding) solves. ... >>can't get past the client firewall. ... > I don't understand why the server would be making the ... server initiates another connection to the client -- in this ...
    (Debian-User)