Indy, Acces Violatio when too many connections

Question

I have three questions:

1. is it possible to destroy IdTCPServer by to many connection? I tried to test my application and when I have several connections - it works very good (even several days) but when sometimes number of connection increases application gives acess violation. I wrote application similates 50 clients sending data constantly (with only sleep(200)). And in this situation IdTCPServer gives exceptions? My application reseives information from clients by onExecute event and modyfies databases table using TidNotify and TIdSync classes. I believe it protects crosses connections threads? Sending information to clients is doing by TTimer (it is only now, I'll change it to other thread). Have I use in this situation special protection or something like that is enough:

   type
     PClient = ^TClient;
     TClient = record
       Activity_time:TDateTime;
       AContext: TIdContext;
     end;
   ...
   list := server.Contexts.LockList;
   try
    for i := 0 to list.Count - 1 do
     with TIdContext(list[i]) do
     begin
   
       if SecondsBetween(now(), PClient(data)^.activity_time) > 6 then
       begin
         Connection.IOHandler.Close;
         Continue;
       end;
       try
         Connection.IOHandler.writeln('E:');
       Except
         Connection.IOHandler.Close;
       end;
     end;
   finally
     server.Contexts.UnlockList;
   end;
   

2.Is a simple way to refuse connection when server is to busy (I think my database isn't complicated (100 rows, only one row is modyfied by one connection) but maybe here is a way to keep stability of server?

3.I know that this question was repeating many times but I didn't find satisfying answer: how to protect application to avoid message exception: "Connection closed gracefully" and "Connection reset by peer"?

Thank You for all advices

Answer 1

is it possible to destroy IdTCPServer by to many connection?

You are asking the wrong question, because you are not actually destroying TIdTCPServer itself, you are simply closing idle connections from an outside thread. That kind of logic can be (and should be) handled inside of the OnExecute event instead, where it is safest to access the connection, eg:

type
  PClient = ^TClient;
  TClient = record
    Activity_time: TDateTime;
    Heartbeat_time: TDateTime;
    AContext: TIdContext;
  end;

procedure TForm1.serverConnect(AContext: TIdContext);
var
  Client: PClient;
begin
  New(Client);
  Client^.Activity_time := Now();
  Client^.Heartbeat_time := Client^.Activity_time;
  AContext.Data := TObject(Client);
end;

procedure TForm1.serverDisconnect(AContext: TIdContext);
var
  Client: PClient;
begin
  Client := PClient(AContext.Data);
  AContext.Data := nil;
  if Client <> nil then Dispose(Client);
end;

procedure TForm1.serverExecute(AContext: TIdContext);
var
  Client: PClient;
  dtNow: TDateTime;
begin
  Client := PClient(AContext.Data);
  dtNow := Now();

  if SecondsBetween(dtNow, Client^.Activity_time) > 6 then
  begin
    AContext.Connection.Disconnect;
    Exit;
  end;

  if SecondsBetween(dtNow, Client^.Heartbeat_time) > 2 then
  begin
    AContext.Connection.IOHandler.WriteLn('E:');
    Client^.Heartbeat_time := dtNow;
  end;

  if AContext.Connection.IOHandler.InputBufferIsEmpty then
  begin
    if not AContext.Connection.IOHandler.CheckForDataOnSource(100) then
      Exit;
  end;

  // process incoming data as needed ...

  Client^.Activity_time := Now();
end;

Is a simple way to refuse connection when server is to busy (I think my database isn't complicated (100 rows, only one row is modyfied by one connection) but maybe here is a way to keep stability of server?

The current architecture does not allow for refusing connections from being accepted. You can let the server accept connections normally and then close accepted connections when needed. You can do that in the OnConnect event, or you can set the server's MaxConnection property to a low non-zero number to allow the server to auto-disconnect new connections for you without wasting resources creating new TIdContext objects and threads for them.

Another option is to call the server's StopListening() method when the server is busy, so that new connections cannot reach the server anymore, and then call the server's StartListening() method when you are ready to accept new clients again. Existing clients who are already connected should not be affected, though I have not actually tried that myself yet.

I know that this question was repeating many times but I didn't find satisfying answer: how to protect application to avoid message exception: "Connection closed gracefully" and "Connection reset by peer"?

You should not avoid them. Let them happen, they are normal errors. If they are happening inside of the server's events, just let the server handle them normally for you. That is how TIdTCServer is designed to be used. If they are happening outside of the server's events, such as in your timer, then just wrap the socket operation(s) in a try/except block and move on.