Passive and active sockets

Quoting from this socket tutorial:

Sockets come in two primary flavors. An active socket is con­nect­ed to a remote active socket via an open data con­nec­tion... A passive socket is not con­nect­ed, but rather awaits an in­com­ing con­nec­tion, which will spawn a new active socket once a con­nec­tion is es­tab­lished ...

Each port can have a single passive socket b开发者_运维百科inded to it, await­ing in­com­ing con­nec­tions, and mul­ti­ple active sockets, each cor­re­spond­ing to an open con­nec­tion on the port. It's as if the factory worker is waiting for new mes­sages to arrive (he rep­re­sents the passive socket), and when one message arrives from a new sender, he ini­ti­ates a cor­re­spon­dence (a con­nec­tion) with them by del­e­gat­ing someone else (an active socket) to ac­tu­al­ly read the packet and respond back to the sender if nec­es­sary. This permits the factory worker to be free to receive new packets. ...

Then the tutorial explains that, after a connection is established, the active socket continues receiving data until there are no remaining bytes, and then closes the connection.

What I didn't understand is this: Suppose there's an incoming connection to the port, and the sender wants to send some little data every 20 minutes. If the active socket closes the connection when there are no remaining bytes, does the sender have to reconnect to the port every time it wants to send data? How do we persist a once established connection for a longer time? Can you tell me what I'm missing here?

My second question is, who determines the limit of the concurrently working active sockets?

The sender should send a KEEPALIVE packet at regular intervals to keep the connection alive. The format of the KEEPALIVE depends on the protocol. It could be as small as a single NULL in the TCP data segment.

As to the second question... it depends on the I/O. If it is blocking I/O then you only want a certain number of threads running on your computer, so you won't be able to have many clients. If it's non-blocking, you can have a lot more clients. Programming languages should have support for both blocking and non-blocking I/O. (I know for a fact that Java does.)

It also depends on things like bandwidth, the data transfer for each client, memory, clock speed, etc. But non-blocking vs. blocking can make a huge difference in the number of clients you can accept. You probably can't have more than 5-10 clients blocking without your server crashing... but you can have thousands if you're not blocking.

Please do not confuse actual packets sent by TCP/IP implementation over network and interaction between your program and a library that implements TCP/IP.

The socket is just an abstraction that is presented to your program by TCP/IP implementation (library or kernel OS). You may visualize socket as connection to the pipe (localIP:port-remoteIP:port). Your program opens socket, communicates data over socket and may close the socket if no longer needed to help free resources. This is normal flow. However TCP/IP implementation may close socket for its own valid reasons. Some of those reasons: network access cable disconnection, network routing errors, server went down, etc. Thus your program may find tcp/ip socket closed even if it did not close it.

Now your first question, what do I do if my program sends small data segments with long pause between them. The answer is: depends on how long is the pause and what program listens you on other side. Most TCP/IP implementations have a notion of connection time out to provide you abstractions of reliable connection over real unreliable networks. Thus if your program will pause longer than tcp/ip timeout you will find your socket been closed by the library and you will need to re-open socket. That may also cause your to restart communication over again, depends on a program that listens for you on other side of the tcp/ip connection pipe.

There are ways of increasing tcp/ip timeout and keeping it alive. Those may be done as part of network configuration, the server software configuration on other end or by you explicitly asking to keep socket open by setting KEEPALIVE parameters in your tcp/ip library call. Would it be still open or not depends. The full details of how tcp/ip would keep socket open should not confuse you as it has nothing to do with your code. TCP/IP has many settings and different timeouts to provide your program with illusion of stable reliable connection. The good part it is all hidden from your program code as long as you not abuse it. Keep your pause under few seconds :) One set of timeout settings may work well for small applications in reliable local network and will not work for high load applications or over cross-continent connectivity. Each specific situation has its own solution, often more than just one.

In this specific question "to send some little data every 20 minutes" I would advise you to close and open socket connection for each communication. The time to open one is less than a second and should not impact your communication. In return you get less complexity in your communication protocol. Receiver is always starts fresh on new socket connection and both systems may enjoy free resources in tcp/ip communication over all 20 minutes when you don't need it.

First question: Yes, once a socket is closed you must do an Open to re-initiate communication.

Second Question: You do. If you want you can create 64k connections to your server and suffer port exhaustion (I don't recommend that). Like ktm5124 stated, it all depends on your application. There are several different ways to make your server scalable including using async I/O and or a thread pool to handle client requests.