Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Porting old Delphi2007 application using TServerSocket....
(07-06-2020, 11:19 PM)BosseB Wrote: Turns out I was close then using IOHandler.ReadLn(ETX), I did not wait for the STX to arrive, though.
Can't I wait for ETX instead so I know a complete message is available?

Yes, which is why I said the call to WaitFor(STX) is optional. But since the protocol dictates that every message begins with STX, it doesn't hurt to validate that actually happens. If every message is well-formed, as it should be for compliant clients, then the WaitFor() will be redundant. But for non-compliant clients, or corrupted communications, waiting for STX before then waiting for ETX can help with recovery efforts.

(07-06-2020, 11:19 PM)BosseB Wrote: I noted that the ReadLn will throw away the ETX char only returning the stuff before.

Yes, so if your processor needs the ETX then you will have to add it to the result, eg:

msg := AContext.Connection.IOHandler.ReadLn(#3) + #3;

(07-06-2020, 11:19 PM)BosseB Wrote: Regarding the OnExecute call, is there some minimum time between the invocations?

No. As soon as the OnExecute handler exits, it is called again immediately.

(07-06-2020, 11:19 PM)BosseB Wrote: And do I actually have to check if there is data before issuing the ReadLn call?

No. It will simply block the calling thread until the specified Terminator is available, or until the specified ReadTimeout elapses.

(07-06-2020, 11:19 PM)BosseB Wrote: Can OnExecute be called without any data having arrived?

Yes, which is why the handler is responsible for waiting for data.

(07-06-2020, 11:19 PM)BosseB Wrote: Is there a way to check how much data there is in queue before actually trying to read it?

The IOHandler.InputBuffer has a Size property. This indicates how many bytes Indy has already read from the socket and stored in the InputBuffer's memory buffer (which the rest of the IOHandler's reading methods then extract their bytes from).

If you want to check how many bytes are in the socket's internal buffer, you will have to access the underlying platform's socket API directly, such as using ioctlsocket(FIONBIO) on Windows. You can get the underlying platform socket handle from the AContext.Binding.Handle property.

(07-06-2020, 11:19 PM)BosseB Wrote: I assume that if I just skip the ReadLn call the data stays in the buffer so the next time around new data arriving gets added to the end of the buffer and can be retrieved with a later ReadLn call?


(07-06-2020, 11:19 PM)BosseB Wrote: I think it will not be a big problem but I have noted when testing that there seems to be a lag in the handling, for example when I connect the client it connects immediately as witnessed by activity in the OnConnect, where I print out the connection message on the console, yet it takes several seconds or more before the client app shows the login dialog to the user in preparation for actually logging in. It is raised as soon as the client discovers the connection succeeded.

Same when sending the login request it is immediately shown in the console but the client takes some time to discover that a valid login has been accepted even though my test code sends the reply immediately after the console has been written to.

Did you have that same problem when using TServerSocket? It sounds like maybe the client's logic has a bug or design flaw in it, where it is not handling socket activity in a timely manner. Maye a buggy socket handler, or a laggy message queue, or something like that. I can't really help you with this without seeing the client's code.

(07-06-2020, 11:19 PM)BosseB Wrote: So if this is caused by the OnExecute firing only at a leisurely rate I need to figure out a better way to discover incoming data arriving...

That is not how the OnExecute event works. There is no "leisurely rate" on it.

I suggest you use a packet sniffer, like Wireshark, to watch the underlying TCP traffic in real-time, so that you can see whether TIdTCPServer is sending its replies in a delay manner after receiving client requests, or whether the client is updating its UI in a delayed manner after receiving the server's replies.


Messages In This Thread
RE: Porting old Delphi2007 application using TServerSocket.... - by rlebeau - 07-06-2020, 11:44 PM

Forum Jump:

Users browsing this thread: 1 Guest(s)