Jump to content

aehimself

Members
 View Profile  See their activity

  • Content Count

    1089

  • Joined

  • Last visited

  • Days Won

    23

Posts posted by aehimself

  2. Posted

    Just now, Uwe Raabe said:

    Seems legit. If you have a horizontal scroll bar there is no need for wrapping anything.

    I can see the logic in there but this is why scrollbars can be disabled. I expected that the horizontal scrollbar will become disabled and word wrapping starts to happen.

     

    Well, anyway. At least it works now.

  3. Posted

    No, RichEdit works just fine. And I accidentally found the solution... it's the scrollbar. 

    Begin
 TextEditor.WordWrap := Not TextEditor.WordWrap;
End;

    doesn't do anything. 

    Begin
 TextEditor.WordWrap := Not TextEditor.WordWrap;
 If TextEditor.WordWrap Then TextEditor.ScrollBars := ssVertical
   Else TextEditor.ScrollBars := ssBoth;
End;

    works like a charm.

  6. Posted

    14 minutes ago, Fr0sT.Brutal said:

    Just foresee that your fixed size could arrive incomplete if it's > 1 byte. I usually read data to buffer to fill header and only then start reading the contents.

    I'm not exactly sure if I got what you meant. The fixed size buffer is only used in the dataavailable evnt to read x bytes out from the socket. Then, there is an inner cycle to process the data in this inner buffer. If a packet ended within it, it copies the missing bytes to a different (variable size; set by the size indicator) buffer, sends that for processing, reads the size indicator and resets it. Until there is nothing else to be processed.

     

    Since I made the latest modifications, this logic seems to function properly - however there was no fragmented packet yet (when the beginning and the end arrive in two different handlers, possibly delayed)

  8. Posted · Edited by aehimself

    9 minutes ago, Anders Melander said:

    The ternary operator.

    Yes, yes, yes, that is the name. I use it a lot, and I keep forgetting it's name. I should seriously consider inking it on my wrist.

    Not only the question mark, though.

    That wouldn't help much.

    9 minutes ago, Anders Melander said:

    For me it somehow breaks the flow when I'm reading code.

    That's the beauty of it, no? For me, inline variable declarations are making the code harder to read, for you it's ternary operators. I have a colleague who always writes if (expression == false) instead of if (!expression) because he admitted he misses the exclamation mark about 80% of the times.

     

    All in all - even if you don't use many of them - it's good to have a bigger toolset to choose from when you are coding. We just have our preferences.

     

    Edit: never thought about it, but do inline variables work like in C#? For example 

    if (condition)
{
 String myStr = "";
}
myStr = "Hello world";

    will not compile, as inline variables are local to the current block. Does it behave the same way in Delphi?

     

    • Like 1

  9. Posted · Edited by aehimself

    Huge +1 to @Der schöne Günther. At work we have 2-5 levels of inherited frames and meet this kind of issue every single day. Reviewing DFMs became a tradition, especially since Delphi tends to move components around with +-1 pixels upon saving - even if you didn't touch them.

     

    Edit: It was like this back in 10.0 Seattle as far as I can remember. It's not only affecting 10.4(.1).

  10. Posted

    4 minutes ago, Anders Melander said:

    Why so sad? Because of the leak?

    Leaks are easy to be fixed, no. I just personally dislike inline variable declarations.

     

    If the Delphi language is moving closer to C#, they could have implemented something useful like Linq or the "?" operator when assigning values to variables (String myVar = inCondition ? "" : otherClass.SringProperty; forgot the name, sorry) in my opinion; that's all.

  11. Posted

    Just now, FPiette said:

    One more important thing: In the OnDataAvailable event, you should read ALL data arriving. So you should make a loop calling Receive until it return < 0. If the buffer used for receive is to small, read anyway in a secondary small buffer and throw data away, then signal the error to the user "buffer to small".

    Yep, that's exactly what I do now. I have an outer cycle: 

            Repeat
         // Receive the fixed size buffer (set in constructor)
         read := Self.Receive(@_rcvbuf[0], Length(_rcvbuf));
         If read <= 0 Then Break;
         [...]
        Until False;

    Within this cycle, I have an internal cycle which is assembling the packets to be decrypted from _rcvbuf; based on the size indicator. If the packet did not fit in _rcvbuf, the next outer cycle will read out the next fragment.

     

    This method seems to be working, packets are flowing in and being decrypted correctly. I just have to wait a couple of days to see if the lock-up happens again or not.
     

    • Like 1

  12. Posted

    2 minutes ago, Kas Ob. said:

    You lost me

    Indeed I did! My brain simply didn't process that the event is not placing the data in the beginning of InBuf... guess I'd finally need some sleep?

     

    I went on with the more difficult version however. I'm reading a fixed size (let's say 200 bytes). If the packet buffer is empty, I read the size and set the packet buffer to that size. If not, I'm appending as many bytes as needed / possible from this 200. If all was processed, I read the next 200 until there's none left. If it works (and I do have my hopes high) I'll move some processing parts to submethods to make the main one easier to read.

  15. Posted · Edited by aehimself

    29 minutes ago, Kas Ob. said:

    And forgot to mention in my sample above there is no mention to the situation were it might fail, it is with the buffer size, example client send two 4k packets and server triggered the DataAvailable event but read only 3k then the rest of the first and the second received, in this case server will read the 2k only and might not get another event to receive again,

    I will be honest, I did not understand how it can stop receiving, up until this point. It all makes sense now.

    I'm in the progress of re-writing it this way, we'll see if that will bring success.

     

    Edit: the lockup indeed happens when there is a significantly larger amount of data incoming (6-7 * 150 bytes instead of 80) so that also confirms this theory. I finished converting the read-out logic and deployed it on the test server. We will see in a couple of days if it worked 🙂

  17. Posted · Edited by aehimself

    Hello,

     

    Most probably this is NOT going to be an issue with ICS as I experienced the very same symptom with TServerSocket before I made the switch. I'm mainly looking for tips on where can I start debugging the issue as for the time being I'm completely out of ideas.

     

    I have an application which is connecting to a server on a single, TCP socket. On average, 80 bytes (binary) are sent from the clients to the server each minute, in one packet. The TCP channel is unidirectional, messages are only going from the client to the server. Everything is working perfectly, until a seemingly random time; when for a seemingly random client the data is not received anymore. The TCP connection is still established, the client is still sending the packet and WireShark confirms that it arrives to the server machine. It seems that the socket's receive event stops firing off. What is even more interesting, that it affects random clients (with different OSes, sometimes Windows 2000, sometimes 2012 R2, sometimes 2019), only causes one client to get stuck at a time, but multiple clients can get stuck during the process. The application can remain in this state for days without memory increase (so I'm not inflating the local buffer endlessly, without triggering the data processing), memory or handle leaks. If I restart the client or the server, forcing the client to reconnect, everything jumps back to normal.

     

    As for a little background, the very same logic was working perfectly, when the binary data was converted to, and sent as text. By switching to binary the sent data size was reduced from 200-500 bytes to 60-100. I don't know why but I suspect this change triggered the error I'm seeing now; and maybe because of the data size.

     

    https://docs.microsoft.com/en-us/troubleshoot/windows/win32/data-segment-tcp-winsock mentions that TCP is not really efficient with unidirectional, small data packets but it only will result delivery delay. For me it seems to be irrelevant.

     

    Sending code looks something like this (TBufferLength = Word): 

    Function TCommunicationEngine.Send(Const inText: String): Boolean;
Var
 buf, len: TBytes;
 sent: Integer;
Begin
 Result := False;
 Try
  // Step 1 - String to TBytes
  buf := TEncoding.UTF8.GetBytes(inText);

  // Step 2 - Encryption of "buf"
  // ...
  
  // If the buffer exceeds the maximum length allowed, raise an error as it can not be sent!
  If Length(buf) > TBufferLength.MaxValue Then Raise ETCPPortError.Create('Buffer overflow, cannot send ' + Length(buf).ToString + ' bytes!');

  // Step 3 - Append the length of the buffer to the beginning of the buffer
  SetLength(len, SizeOf(TBufferLength));
  PBufferLength(@len[0])^ := Length(buf);
  SetLength(buf, Length(buf) + Length(len));
  Move(buf[0], buf[Length(len)], Length(buf) - Length(len));
  Move(len[0], buf[0], Length(len));

  // Step 4 - Send the completed buffer
  sent := _tcpport.Send(@buf[0], Length(buf));

  // Step 5 - Post-sending verifications
  If sent < 1 Then Raise ETCPPortError.Create('No data was sent!');
  Log(LOG_TCP, '> ' + BytesToString(buf) + ' (' + sent.ToString + ' bytes)');
  Result := True;
 Except
  On E:Exception Do HandleException(E, 'while sending data');
 End;
End;

    Receiving block looks like this (TClientConnection is a descendant of TWSocketClient, _data is a strict private TBytes, _count is a strict private Integer): 

    Procedure TClientConnection.ConnectionDataAvailable(inSender: TObject; inError: Word);
Var
 buf: TBytes;
 need, len, read: Integer;
 debuglog: String;
Begin
 // Note that due to how TCP works, if packets are arriving at high speed they might be appended to one single ReceiveText event.
 If BanList.IsBanned(Self.PeerAddr) Then Self.Close // If the IP where the data is coming from is banned, disconnect
   Else Begin
        len := Self.RcvdCount;
        If len = 0 Then Exit;
        Repeat
         debuglog := Self.PeerAddr + ' > Read cycle starts. received data size: ' + len.ToString + ', socket data size: ' + Length(_data).ToString + ', position: ' + _pos.ToString + '. ';
         If _pos = 0 Then Begin
                          // Position is 0 = there is no fragment. Read the data size first
                          If len < SizeOf(Word) Then Begin
                                                     BanList.Failed(Self.PeerAddr, 'Packet size is incorrect');
                                                     Self.Close; // Packet is corrupted, reset the connection
                                                     Exit;
                                                     End;
                          SetLength(buf, SizeOf(TBufferLength));
                          Self.Receive(@buf[0], Length(buf));
                          // buf now contains the data size. Resize socket's data length
                          SetLength(_data, PBufferLength(@buf[0])^);
                          // As the data size is read out, reduce the received length
                          len := len - Length(buf);
                          debuglog := debuglog + 'Prepared a ' + Length(_data).ToString + ' byte buffer. ';
                          End;
         need := Length(_data) - _pos;
         If need < 0 Then Begin
                          // this should never happen. I'll just keep it here for debugging purposes...
                          Log(LOG_STD, 'Possible memory corruption happened. Data size of ' + Self.PeerAddr + ' is ' + Length(_data).ToString + ', position is ' + _pos.ToString);
                          Self.Close;
                          Exit;
                          End
           Else
         If need > 0 Then Begin
                          If len < need Then SetLength(buf, len) // If we received less bytes than needed to fill the buffer, read everything
                            Else SetLength(buf, need); // If we received more bytes than needed to fill th buffer, only read what is needed
                          debuglog := debuglog + 'Reading out ' + Length(buf).ToString + ' bytes. ';
                          read := Self.Receive(@buf[0], Length(buf));
                          If read > 0 Then Begin
                                           debuglog := debuglog + read.ToString + ' bytes read. ';
                                           // Something was read from the buffer. Append it to the socket's data
                                           Move(buf[0], _data[_pos], read);
                                           // Increase data position
                                           Inc(_pos, read);
                                           // Reduce received length
                                           len := len - read;
                                           End
                            Else debuglog := debuglog + 'Nothing was read. ';
                          End;
         If _pos = Length(_data) Then Begin
                                      Log(LOG_TCP, debuglog.TrimRight);
                                      Log(LOG_TCP, Self.PeerAddr + ' > ' + BytesToString(_data) + ' (' + _pos.ToString + ' bytes)');
                                      // Buffer is full. Process the data.
                                      
                                      // Decrypt the buffer...
                                      // ...

                                      Try
                                       ProcessLine(Self.PeerAddr, timestamp, TEncoding.UTF8.GetString(_data));
                                      Except
                                       On E:Exception Do Begin
                                                         Log(LOG_STD, TranslateException(E, 'processing client data'));
                                                         BanList.Failed(Self.PeerAddr, 'data processing error: ' + E.Message);
                                                         Self.Close;
                                                         End;
                                      End;
                                      _pos := 0;
                                      SetLength(_data, 0);
                                      End
           Else
         If Not debuglog.IsEmpty Then Log(LOG_TCP, debuglog.TrimRight);
        Until len = 0;
        If (Length(_data) > 0) Or (_pos > 0) Then Log(LOG_TCP, 'Storing a fragment for ' + Self.PeerAddr + ': Data size: ' + Length(_data).ToString + ', position: ' + _pos.ToString);
        End;
End;

    I know that there are a couple of premature exits before the actual data processing, but even when I added temporary logging before these, none of them was reached.

     

    I'll investigate on how I can, and will try to add TCP_NODELAY and SO_SNDBUF, but I doubt that they will make any difference. Until then, I'm really interested what are the aspects what I did not even think of until now.

     

    I'm using ICS v8.64, application is compiled using Delphi 10.4.1 as a 32-bit executable, and is executed as a Windows service on a Server 2012 R2 machine.

     

    Any help is greatly appreciated 🙂

  20. Posted

    12 hours ago, FPiette said:

    You should display the ErrCode argument in OnSessionConnected event handler.

    And I seriously missed that, I just don't know how. Using the SessionConnected handler WITH a small check to the error code works - as designed I suppose 🙂

    Let's hope that changing to a little bit more up-to-date component will solve the connectivity issues I had!

     

    10 hours ago, Angus Robertson said:

    You can not use state alone to know when a connections succeeds. 

    This was the part I was missing; coming from an old, outdated component I expected the stateflow to be different if a connection attempt fails or succeeds. I was just unsure if I did something wrong in other parts of my code, or not.

    I'm an ICS newbie. I'll learn 🙂

  21. Posted

    Hello,

     

    I would like to have a TMemo in my application, where the user could manually toggle the WordWrap property. When changing this property though runtime, the change has no effect on the display whatsoever.

    I did my homework, and I see only one reference to FWordWrap in the TCustomMemo implementation, which is this block: 

    procedure TCustomMemo.CreateParams(var Params: TCreateParams);
const
  ScrollBar: array[System.UITypes.TScrollStyle] of DWORD = (0, WS_HSCROLL, WS_VSCROLL,
    WS_HSCROLL or WS_VSCROLL);
  WordWraps: array[Boolean] of DWORD = (0, ES_AUTOHSCROLL);
begin
  inherited CreateParams(Params);
  with Params do
    Style := Style and not WordWraps[FWordWrap] or ES_MULTILINE or ScrollBar[FScrollBars];
end;

    The setter looks like this: 

    procedure TCustomMemo.SetWordWrap(Value: Boolean);
begin
  if Value <> FWordWrap then
  begin
    FWordWrap := Value;
    RecreateWnd;
  end;
end;

    Placing a breakpoint in CreateParams confirms that RecreateWnd triggers the call of CreateParams, where FWordWrap already has the most recently set value, however it does not change the behavior.

     

    Google only lead me to one question on the FPC forums, but with no viable solution. Is there a way to make this work without using a 3rd party component?

  23. Posted

    On 9/22/2020 at 1:28 PM, Fr0sT.Brutal said:

    Offtop: I'm always wondering why people tend to write "APP" (in uppercase) when it's just a short form of "application". Nobody says "I wrote an APPLICATION".

    Because it's the mainstream. I bet my shoes on that you can track it back to Apple.

  24. Posted · Edited by aehimself

    Hello,

     

    I'm in the process to migrate an old code from TClientSocket to an ICS TWSocket. All seems to work fine, except the OnConnect & OnDisconnect handlers.

     

    Create a new VLC project, with a TWSocket and a memo on it and use the following code: 

    Function SocketStateToString(Const inSocketState: TSocketState): String;
Begin
 Case inSocketState Of
  wsInvalidState: Result := 'invalid';
  wsOpened: Result := 'opened';
  wsBound: Result := 'bound';
  wsConnecting: Result := 'connecting';
  wsSocksConnected: Result := 'socks connected';
  wsConnected: Result := 'connected';
  wsAccepting: Result := 'accepting';
  wsListening: Result := 'listening';
  wsClosed: Result := 'closed';
  wsDnsLookup: Result := 'DNS lookup';
  Else Result := 'unknown';
 End;
End;

procedure TForm3.FormCreate(Sender: TObject);
begin
 WSocket1.Connect;
end;

procedure TForm3.WSocket1ChangeState(Sender: TObject; OldState,
  NewState: TSocketState);
begin
 Memo1.Lines.Add('State change from ' + SocketStateToString(OldState) + ' to ' + SocketStateToString(NewState));
end;

procedure TForm3.WSocket1SessionClosed(Sender: TObject; ErrCode: Word);
begin
 Memo1.Lines.Add('Session closed');
end;

procedure TForm3.WSocket1SessionConnected(Sender: TObject; ErrCode: Word);
begin
 Memo1.Lines.Add('Session connected.');
end;

    Set the WSocket's Addr to 127.0.0.1 and the port to 1024. Make sure no application listens.

     

    When I run the above code, I get the following result:

     

    State change from closed to opened
    State change from opened to connecting
    State change from connecting to connected
    Session connected.
    State change from connected to closed
    Session closed
     

    The state goes to connected for a brief moment, also session is connected... to nothing (?) before both goes back to closed.

     

    What is the normal place to put my code in, which is granted to run ONLY if the socket was really connected and disconnected?

     

    Edit: I'm using ICS vV8.64 on Delphi 10.4.1

×