The other issue I see is if one message doesn't come as one IP-packet but is split up. And I don't see that case handled in your code. What I mean is, if you send two messages from the client, and after both arrived then you call RecvPacket (and not earlier), then I would expect the function to return the data holding both messages as one string. The docu I also read, and it doesn't say anything about packets, just the available data of the byte stream. So when you call RecvPacket how can you be sure that what you receive is the complete data and not only half of a message or several messages combined?įor that I'm still not convinced. I'm not sure about the synapse library, but as far as I understand the TCP-protokoll the incoming data is just a byte stream and not bundled in packets. in TClientThread.RecvMessage (line 685 of uTCPSockets). Can you say something to that data handling concept? Or is it just to guarantee a cache flush?Īdditionally I wouldn't expect the access to unt to be thread safe, but I'm not sure.
That copy sequence is protected in a critical section, but as the list is thread specific, that critical section seems to protect nothing. The task list is accessed in the Execute method of the client thread and first the count property is checked and then in case it is not zero the list is copied to a local TList. from TfMain.miBroadcastMessageClick via FTCPServer.SendMessage). I don't see any protection there when TList.Add is called in order to add a task (E.g. within the main thread, the task list is then polled by the TClientThread of the server application.
Two questions:Īs I understand you add tasks to the task list e.g.
#SYNAPSE LIBRARY FOR FREE PASCAL CODE#
Thanks for sharing! I'm studying and trying to understand your code right now, especially the data handling between the threads.
0 kommentar(er)
