FearDC

Thank you for help @Remy Lebeau. I will figure out some sort of priority outbound buffer with instant flushing. I might ask more questions, but later in that case. Regards.

Thank you for your reply @Remy Lebeau. I'm having hard time to understand what an "unsolicited" notification/response is - kind of "unexpected"? I will provide you with short example of client to server handshake and further communication. Client to server handshake: Next part is a free communication where client talks first: Another moment is where server talks first notifying everyone that someone enters or leaves: That's it basically. When a client connects, the server creates a separate thread where it handles reads and writes from/to client. It first welcomes the client, exchanges the handshake information and waits for requests from client. Possibly sends public notifications to client. I don't really understand why the above would not work. Or do you mean that client will not be written to while server is reading the client - client thread is frozen and waiting for data from client? In that case there is timeout - is that the delay you are talking about? Sorry, english is not my primary language, so it's not always I understand everything even if I try to translate. Also the logical part is the hardest part for me, even in real life, while writing the code is the easiest. 😛 Regards.

Hi. I'm currently working on a heavily-loaded TCP server in Delphi 12 using latest version of Indy 10, which will run on both Windows64 and Linux64. There are over 3.000 concurrent clients connected to the server, every each of them is a persistent TCP connection using custom protocol - request/response based. Each connection is handshaked with as unique user with unique nickname/ID. These requests are properly validated by several helpers like protocol parser, ban list, protocol feature support, flood detection, etc. So they involve shared memory access, hard-drive access, within and outside Indy classes. The requests can be multiple, they can be one at a time, they can be ten or more at a time, from each client. Main priority for the server is to follow the request/response order, otherwise protocol exchange will get out of sync between each connection and server. Connected users are also notified about connection/disconnection of other users. So the actual logical advises I'm seeking is the correct/best way to perform this protocol synchronization, aswell as serving the requests in correct order. I will supply a basic class implementation of my application and write a few comments inside about which does what. Server class: type TOnUserConnect = procedure(AConn: TIdContext) of object; TOnUserDisconnect = procedure(AConn: TIdContext) of object; TOnUserDataIn = procedure(AConn: TIdContext; const AData: String) of object; TOnUserDataOut = procedure(AConn: TIdContext; const AData: String) of object; type // server listener TMyServer = class(TIdCustomTCPServer) protected procedure InitComponent; override; private FOnUserConnect: TOnUserConnect; FOnUserDisconnect: TOnUserDisconnect; FOnUserDataIn: TOnUserDataIn; procedure OnSocketConnect(AConn: TIdContext); // note: thread safety procedure OnSocketDisconnect(AConn: TIdContext); // note: thread safety procedure OnSocketExecute(AConn: TIdContext); // note: thread safety procedure DoParseProtocol(AConn: TIdContext; const AData: String); public LWaitFor: String; // command separator FOnUserDataOut: TOnUserDataOut; property OnUserConnect: TOnUserConnect read FOnUserConnect write FOnUserConnect; property OnUserDisconnect: TOnUserDisconnect read FOnUserDisconnect write FOnUserDisconnect; property OnUserDataIn: TOnUserDataIn read FOnUserDataIn write FOnUserDataIn; property OnUserDataOut: TOnUserDataOut read FOnUserDataOut write FOnUserDataOut; end; procedure TMyServer.InitComponent; begin inherited InitComponent; Self.ContextClass := TMyClient; Self.OnConnect := Self.OnSocketConnect; Self.OnDisconnect := Self.OnSocketDisconnect; Self.OnExecute := Self.OnSocketExecute; // Self.OnUserDataIn is bound below only to show short version, // otherwise it is specified in TMyServer parent class which is // actual protocol parser, user validator, and main worker Self.OnUserDataIn := DoParseProtocol; end; procedure TMyServer.OnSocketConnect(AConn: TIdContext); begin TThread.Queue(nil, procedure begin if Assigned(Self.FOnUserConnect) then Self.FOnUserConnect(AConn); end ); end; procedure TMyServer.OnSocketDisconnect(AConn: TIdContext); begin TThread.Queue(nil, procedure begin if Assigned(Self.FOnUserDisconnect) then Self.FOnUserDisconnect(AConn); end ); end; procedure TMyServer.OnSocketExecute(AConn: TIdContext); var AData: String; begin AConn.Connection.IOHandler.ReadTimeout := 5000; AData := AConn.Connection.IOHandler.WaitFor(LWaitFor); TThread.Queue(nil, procedure begin if Assigned(Self.FOnUserDataIn) then Self.FOnUserDataIn(AConn, AData); end ); end; procedure TMyServer.DoParseProtocol(AConn: TIdContext; const AData: String); var AUser: TMyClient; begin AUser := AConn as TMyClient; if AData.Equals('Validate') then begin AUser.FNick := '<parsed data>'; // below code will send response data to user directly - the connection will be written to, // but note that it's done inside Thread.Queue() - is this correct, or do i need to // step outside and perform the actual write? maybe some kind of internal buffer queue // that will write on OnServerExecute() to each connection? AUser.SendData('Hello'); end else if AData.Equals('<bad command>') then begin // below code will disconnect the user, also inside Thread.Queue() - is this safe from here? AUser.Connection.Disconnect; end; // this is the actual protocol parser, from here user connection will be // verified, protocol parsed, responses written, other helper classes // will check for bans, shared memory access will be performed, file // contents will be read from hard drive and sent back to users, // thread-unsafe objects will be used, users will get disconnected, // basically all the main load will be performed here end; { ... } Client class: type // user connection TMyClient = class(TIdServerContext) protected // private FNick: String; FFeatures: TStrings; procedure SendData(const AData: String); public constructor Create(AConn: TIdTCPConnection; AYarn: TIdYarn; AList: TIdContextThreadList = nil); override; destructor Destroy; override; end; constructor TMyClient.Create(AConn: TIdTCPConnection; AYarn: TIdYarn; AList: TIdContextThreadList = nil); begin inherited Create(AConn, AYarn, AList); FNick := ''; FFeatures := TStrings.Create; end; destructor TMyClient.Destroy; begin FFeatures.Free; inherited Destroy; end; procedure TMyClient.SendData(const AData: String); begin if Self.Connection.Connected then begin Self.Connection.IOHandler.Write(AData); if Assigned((Self.Server as TMyServer).FOnUserDataOut) then (Self.Server as TMyServer).FOnUserDataOut(Self, AData); end; end; // in this class connection will be written to, disconnected, etc { ... } I know about Indys internal write buffering, it will be filled with an amount and written when maximum size is reached - this is exactly what I need, so basically I don't need some kind of internal buffer implementation for outbound data. Thread syncing is required to step outside Indys threads in order to access shared data - what ever that could be. I do that, but I'm not sure if the actual write or disconnect against clients is the right place to perform. Well, I hope you get the logic of my server - if not, please let me know, I will describe further. Any advise is appreciated. Regards.

Thank you for your reply @DelphiUdIT. I have been reading on Wiki, but I use D12. Currently Indy does not have 290 package it seems. There is a PR#517, but it mentions 280 too many times (btw I left a review comment for that PR author). I was thinking rather some solution like pull/299#issuecomment-675003145 - atleast for now, until 290 is fully supported. I could be a test case for sure, to help finding issues, if there are any. Anyway @DelphiUdIT, could you please tell more about problems that Indy upgrade caused to your D11? Regards.

I'm sorry but I don't understand how to do this properly. I did clone https://github.com/IndySockets/Indy/pull/299 into local directory, added it to library path. I have Delphi 12 and up-to-date IdCTypes.pas and IdGlobal.pas. So what is next? 😛

Oh, cool. Does IdStackBSDBase have recv() too?

Thank you for hint @Remy Lebeau.

Finally got it working. type TTimeVal = record tv_sec, tv_usec: LongInt; end; var mTime: TTimeVal; mRes: Integer; begin mTime.tv_sec := 5; mTime.tv_usec := 0; // returns 0 - no error mRes := Posix.SysSocket.SetSockOpt(AContext.Binding.Handle, SOL_SOCKET, SO_RCVTIMEO, &mTime, SizeOf(TTimeVal)); Thank you for hints @Virgo.

SetSockOpt from Posix.SysSocket/SysSocketAPI.inc The second one is Indys built-in. I know that Posix wants a time struct, but how to do that in Delphi? Regards.

I need to perform simple TCP socket peek during Indy server event. To do this I use recv(), but it stays blocking forever if I don't receive required data, not allowing any further server <> client communication. procedure OnServerBeforeConnect(AContext: TIdContext); var mPeek: Array [0..1] of AnsiChar; mTime, mRes: Integer; begin { // returns error -1 mTime := 5; mRes := SetSockOpt(AContext.Binding.Handle, SOL_SOCKET, SO_RCVTIMEO, mTime, SizeOf(mTime)); } { // nothing happens AContext.Binding.SetSockOpt(Id_SOL_SOCKET, Id_SO_RCVTIMEO, 5); } // hangs forever if (Recv(AContext.Binding.Handle, mPeek, 2, MSG_PEEK) = 2) and (mPeek[0] = #22) and (mPeek[1] = #03) then TIdSSLIOHandlerSocketOpenSSL(AContext.Connection.IOHandler).PassThrough := False; end; On Windows this works just fine, setting SO_RCVTIMEO helps to exit recv() even if needed data is not received. Please help. Regards.

Sorry, I was tired yesterday. Everything works as expected! I was simply connecting to wrong mapped address.

Environment: Indy 10.6.2.0, Delphi 12, Ubuntu 20.04 I'm going completely mad about this, because there is no socket I/O what so ever after accept: Same code works fine on Windows: program LinuxMapper; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.Classes, IdMappedPortTCP, IdContext, IdGlobal; type TMyClass = class protected // private mServ: TIdMappedPortTCP; procedure OnServerConnect(AContext: TIdContext); procedure OnServerExecute(AContext: TIdContext); public // end; procedure TMyClass.OnServerConnect(AContext: TIdContext); begin TThread.Queue(nil, procedure begin WriteLn('OnConnect from ' + AContext.Binding.PeerIP + ' to ' + AContext.Binding.Port.ToString); end ); end; procedure TMyClass.OnServerExecute(AContext: TIdContext); begin TThread.Queue(nil, procedure begin WriteLn('OnExecute from ' + AContext.Binding.PeerIP + ' to ' + AContext.Binding.Port.ToString); end ); end; var mSelf: TMyClass; begin try mSelf := TMyClass.Create; mSelf.mServ := TIdMappedPortTCP.Create; mSelf.mServ.OnConnect := mSelf.OnServerConnect; mSelf.mServ.OnExecute := mSelf.OnServerExecute; mSelf.mServ.DefaultPort := 1234; with mSelf.mServ.Bindings.Add do begin IPVersion := Id_IPv4; IP := '1.2.3.4'; Port := 1234; end; mSelf.mServ.MappedHost := '4.3.2.1'; mSelf.mServ.MappedPort := 4321; mSelf.mServ.Active := True; while True do Sleep(100); // .. except on E: Exception do WriteLn(E.ClassName, ': ', E.Message); end; end. Regards.

Thank you @Remy Lebeau, you are very helpful as usual! procedure OnServerBeforeConnect(AContext: TIdContext); var mTime: Integer; mPeek: Array [0..1] of AnsiChar; begin AContext.Binding.GetSockOpt(Id_SOL_SOCKET, Id_SO_RCVTIMEO, mTime); AContext.Binding.SetSockOpt(Id_SOL_SOCKET, Id_SO_RCVTIMEO, 5); if (Recv(AContext.Binding.Handle, mPeek, 2, MSG_PEEK) = 2) and (mPeek[0] = #22) and (mPeek[1] = #03) then // client hello TIdSSLIOHandlerSocketOpenSSL(AContext.Connection.IOHandler).PassThrough := False; AContext.Binding.SetSockOpt(Id_SOL_SOCKET, Id_SO_RCVTIMEO, mTime); end;

@Remy Lebeau Since ICS does not support Linux yet, I would like to use Indy instead. My application requires TLS 1.3, but I will figure this out later, since I heard that TLS 1.3 is possible with Indy using some modifications. Now to my project.. There is a TCP server listening on incoming connections, it checks whether client supports TLS or not using magic bytes detection as described earlier (client hello > client sends 22+03 bytes on first read), then accepting TLS or passing through, and mapping protocol data to destination server. I have tried using TIdMappedPortTCP, but without success, guess because InputBuffer has already been received by the point where OnExecute is executed. So it seems that I need to clone and modify TIdMappedPortTCP - which I did too. But in order to start proper "PassThrough := False" and "StartSSL" after "AContext.Connection.IOHandler.CheckForDataOnSource(0)" and "AContext.Connection.IOHandler.InputBuffer.PeekByte(0) == 22 and AContext.Connection.IOHandler.InputBuffer.PeekByte(1) = 03", it seems that I need to modify TIdCustomTCPServer aswell, in order to "undo" already received buffer. I'm almost there anyway, but I need your help, since you are expert in Indy. Could you please help me? If something of what I said is unclear, please let me know. I will try to describe even better. Regards.

So you mean that it is not possible to just install kqueue library + headers on my Linux distro? It has rather be a part of Linux kernel, like on BSD or MacOS? If yes, then what if we conditionally replace kqueue with epoll, like you already started implementing in ICS10, will it work? With other words - is kqueue the last thing that can't get past compilation in ICS, or are there more similar cases? Regards.