Jump to content

FearDC

Members
  • Content Count

    33
  • Joined

  • Last visited

Community Reputation

1 Neutral

About FearDC

  • Birthday 05/05/1986

Technical Information

  • Delphi-Version
    Delphi 12 Athens
  1. FearDC

    ICS V9.4 announced

    Resolved my issue. Project was using old 9.2 source path. Thank for your time.
  2. FearDC

    ICS V9.4 announced

    Hm, very strange. I do open my form in IDE, Delphi 12. And my DFM contains SslCipherList13 filter correctly. I updgraded from ICS 9.0 to 9.4. I have not opened my project in between.
  3. FearDC

    ICS V9.4 announced

    I'm pointing out that my application crashes with above error message after updating ICS components to version 9.4. The only solution is to erase SslCipherList13 competely. But after closing and opening the project, the SslCipherList13 list is back by itself, and my program crashes again. I would like to understand why this happens. LOL.
  4. FearDC

    ICS V9.4 announced

    Seems like there are 3 problems: 1. Changelog has a typo, should be "P-521" 2. Default value of SslCipherList13 if not empty 3. SslCipherList13 property no longer exists Regards.
  5. FearDC

    ICS V9.4 announced

    Hi. Anyone can help me with this runtime error? "Beware old SslContexts may include group P-512 which must be corrected to T-521" from 9.3 changelog is little bit unclear to me. I however changed in SslCryptoGroups from P-512 to T-521. Is this correct? Regards.
  6. 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.
  7. 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.
  8. 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.
  9. FearDC

    TLS v1.3

    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.
  10. FearDC

    TLS v1.3

    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? 😛
  11. FearDC

    [Need help] Linux recv() timeout

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

    TIdMappedPortTCP not executing on Linux

    Thank you for hint @Remy Lebeau.
  13. FearDC

    [Need help] Linux recv() timeout

    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.
  14. FearDC

    [Need help] Linux recv() timeout

    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.
  15. FearDC

    [Need help] Linux recv() timeout

    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.
×