I am writing a service for file synchronization: there is a server and a large number of clients interacting with it; interaction is reduced to a simple notification of some clients about changes that have occurred on the server.

What will be more effective in this case (both in time and in the costs of system resources):

  • continuously maintain a TCP connection with each client and send notifications from the server,
  • or force each client every 5-10 seconds. send a UDP packet with a request for new alerts?

What approach is used for similar tasks: Dropbox, Jabber (notifications of new messages), Vkontakte?

  • VKontakte, Dropbox, jabber use tcp. But in a local network it can be much more efficient to use udp (multicast). But you just need to remember that udp can be lost. - KoVadim
  • one
    @Jofsey, with a really large number of clients (tens of thousands), it will not be possible to maintain constant TCP connections of one server (network interface) with all of them, since The size of the IP port at the server is limited to 16 bits. In general, without a more detailed description of what you are doing, how this system should function, what are the requirements for reliability, reaction time in different situations, etc. give good advice will not work. - avp 4:04 pm
  • > server IP port size is limited to 16 bits Shtow. 2 ^ 16 - this limit on the number of connections for only one pair of addresses (that is, connections per client, if you don’t touch NAT). - drdaeman 4:39 pm
  • More precisely, this is the limit on the number of connections on the socket that the server uses in accept (), and not on one client at all. In reality, this number is even smaller (ports 0-1023 and the port on which the server did bind are not used). - avp