Prevent too many connect attempts.

[kapibara]

Using indy for a TCP/IP server, is it possible to prevent a user from trying to connect too often?

[sash]

Broad answer to a broad question:
At server side, you cannot prevent anything one does at the other (client) side.

However, on a server you can limit (drop) connections by their max total number, or based on some session mechanism.

[Thaddy]

Yes, you need a simple stack per connection that pushes the ip address and drop connection on sizeof(stack).
A better way is to use some software like fail2ban which does that for you. It is only a first line of defense, mind you, but that is what I use -among other protections - and works.

Similar software as fail2ban can be written in fpc, if you are a purist, but I would not take the trouble.
https://en.wikipedia.org/wiki/Fail2ban which also links to similar industry standards.

I personally have much pleasure in finding out the idiots....and reading logs..

[Remy Lebeau]

Using indy for a TCP/IP server, is it possible to prevent a user from trying to connect too often?

Not directly, no.  You would have to keep track of client information over time (IP, username, whatever), and then whenever a new client connects, close that connection immediately if that client is already being tracked and it is too soon for that client to be allowed to reconnect.

On Windows only, a slight variation of this would be to define your own class that derives from Indy's TIdStackWindows class, and then call Indy's IdStack.SetStackClass() function during app startup.  Have your derived class override the virtual Accept() method to call Winsock's WSAAccept() function instead of the BSD-style accept() function that TIdStackWindows.Accept() calls by default.  WSAAccept() allows you to use a callback function to accept/reject clients while they are still in the server socket's backlog before they are accepted by the application.  Thus, Indy would not even see any clients that you decided to reject, and so won't waste any time and resources on them.

That being said, this is probably something that would be better handled using a load balancer, firewall, etc, sitting in front of the server, not handled in the server's own code.

[kapibara]

Thanks, then I'll handle it with software outside of the server code.