This is the background: the client and server exchange one message at a time, the server does not make sense to keep a list of all clients, i.e. with each is a separate work. The server, in fact, performs work with the database and provides data to each client, depending on the client's request. So I have this question: "What will be less loading the server: contain a stream that listens to client requests and respond to them until the client disconnects, or kill the stream and socket after each response to a user request and create again when the user connects? "

    2 answers 2

    The answer depends on the specific situation. When choosing, keep in mind the following:

    • how often clients perform some actions, i.e. downtime
    • do I need to be able to send messages to the client
    • how critical is delay due to peeconnection

    It is clear that if a client often makes some requests, then if you reconnect every time, the cost of connections may increase. And most importantly, with this approach, performance can drop dramatically due to the fact that the connection takes at least about two or three pings and sometimes more. So if the client reconnects often, then you lose.

    Keeping the connection active requires memory. If keep-alive is enabled, then from time to time it is still necessary to send it and receive, process timeouts.

    In most cases, it is still preferable to keep the connection open until some timeout occurs, until the connection is terminated or the number of connections exceeds a certain value, and the connection is not used for a while. In general, there are several statistics on this subject.

    UPD

    Keep in mind two more things: the number of open sockets in the system is limited (including the number of local ports), and if there are a lot of connections to keep-alive, there can be lags in the network. Therefore, I recommend doing the following:

    • set a limit on the number of connections
    • keep inactive sockets in any queue in the order of the last call, and if necessary, close the oldest unused
    • optionally, you can close sockets that are not used for T minutes (choose a constant according to circumstances)
    • Thank! In principle, messaging does not happen often, so I generally thought about closing threads. The client sends requests when it needs some information from the database on the server, something like that. The solution I found is Java NIO. Those. I’ll keep the sockets open, but I don’t have to spend more on threads since there event handling is provided for if someone wants to connect, open a socket to it, if someone sent a request, then process the request and respond to it, etc. Those. I do not need to feed many streams that will sit and wait for the client to ask something. - ruslanys
    • 2
      Only when dealing with the strategy of closing old connections initiated by the server, one should keep in mind that clients should respond to this correctly, and not assume that the server has "dropped". - avp
    • @avp thanks, I will consider - ruslanys

    Again the topic of a spherical horse in a vacuum.

    Try to implement first one approach, then if you are not satisfied - implement a different approach. When I implemented a business logic server in C #, I used asynchronous sockets . Judging by what was written in the article, from which I gathered this information, it was a rather productive option that could serve up to 4,000 connections. There is probably something like that in Java.

    • I understood it. I know how to implement this, I was just interested to know what is cheaper: to feed the stream, even if it is waiting for the client’s command, or to spend money on re-initializing the socket, opening in \ out streams, etc. - ruslanys