Bob Ippolito <[EMAIL PROTECTED]> writes: > You are very confused. Forking and sockets have nothing to do with each > other. In the CherryPy case, it isn't even forking, it's threads. You > should read up on TCP instead of confusing everyone else.
How can you get to answer to 2 simultaneous clients on the same port at the same time without multicast/broadcast then? Threads allow you to run concurrent things but they don't magically turn your physical medium into something that can carry more information at the same time. > What's happening here is that CherryPy isn't eagerly closing down the TCP > sockets as quickly as Apache is apparently doing. No more, no less. If the > connections were to remain open with Apache you'd see 20 connections from 20 > different origin ports. CherryPy is only LISTENING on one port, just like > Apache. This is almost definitely harmless, but it's probably worth taking > a look into seeing why they're staying alive... it might just be HTTP > Keep-Alive with a more optimistic timeout than what Apache is using. If you take a look at the hyperlink I've sent before and at some other documents that talk about TCP TIME_WAIT you'll see that it has nothing to do with Apache, CherryPy or keep-alive. It is a TCP connection state that is expected to exist. As I said before, all these were finished and the OS is just waiting for them to timeout and close them. Of course there are means to reuse connections and to improve that, but this is not what is happening on his message. -- Jorge Godoy <[EMAIL PROTECTED]>
