While I agree with you, the issue seems to be a little more complex.
I've tried this connection over the internet, client on a remote
location, server running locally. It still shows the same issue.
What's ever more odd is that I switched the writing to TMemo.Lines with
a sleep(), to see how long waiting is required to get things running.
When running locally (both client and server on the same macine), a
sleep(1) is enough to 'work around' the issue. When running the client
on a remote site, I have to up this to sleep(100) to make things work
(sleep(50) didn't work ok, didn't try between 50 and 100).
So long story short, the slower the network connection, the longer the
sleep has to be to get things working, which gives me the feeling it's
not a normal 'two things happening at nearly the same time' kind of problem.
On 04/09/2014 15:04, Angus Robertson - Magenta Systems Ltd wrote:
No, I can't reproduce using that URL, I'm not really sure what
triggers the situation
I have seen cases where a bug that shows up during testing on a fast LAN is
never reproduced on real world servers and networks.
Try adding bandwidth limiting to your client to slow down the speed on the LAN.
Set BandwidthLimit to bps, and add HttpoBandwidthControl to Options.
This is an alternate to adding extra delays which is effectively what you are
doing by updating the screen.
There is probably a race condition somewhere, that has yet to be found.
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be