(07-06-2020, 11:44 PM)rlebeau Wrote:(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.
Now after I have implemented the changes you suggested I also moved the application to Linux (Raspbian) and compiled it there. So I can compare the server behavior on Linux vs. on Windows.
It turns out that when exactly the same code is compiled and executed on Windows and on Linux the Linux version does not show this lag when using exactly the same client on Windows 10 as I used before.
I can run the server on both platforms and connect to each by changing the host value, and when connecting to the Linux server the response is immediate. The login dialog appears instantly, whereas if I connect to the Windows based server there is a delay of maybe 5 seconds before that happens.
I now believe it is caused by Windows10 "trying to be clever"....
Not an Indy or FPC issue.
And in any case it is not an issue to me for the whole exercise is to move the server to Linux anyway.
Thanks for your help!