wonderful examples !You're welcome! I attach a slightly improved versions.
Thank You !
As I understand you add tasks to the task list e.g. within the main thread, the task list is then polled by the TClientThread of the server application. I don't see any protection there when TList.Add is called in order to add a task (E.g. from TfMain.miBroadcastMessageClick via FTCPServer.SendMessage). 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. That copy sequence is protected in a critical section, but as the list is thread specific, that critical section seems to protect nothing. Or is it just to guarantee a cache flush?The idea behind TTaskList is that in order to broadcast a message, we have to lock, then loop through the server's client list. If we perform the actual broadcasting from inside the loop, the server will become unresponsive. By using a thread safe TTaskList, we offload the bulk of the work to the execute event of each client, this way minimize the amount of time the list needs to be locked.
Additionally I wouldn't expect the access to TList.count to be thread safe, but I'm not sure. Can you say something to that data handling concept?
You use RecvPacket several times, e.g. in TClientThread.RecvMessage (line 685 of uTCPSockets). 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. 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?I will quote from Synapse documentations:
Method reads all data waiting for read. If no data is received withinAfter a RecvPacket usually I check for errors(FBlockSocket.LastError > 0), so if something went wrong I will know it.
TIMEOUT (in milliseconds) period, @link(LastError) is set to WSAETIMEDOUT.
Methods serves for reading unknown size of data. Because before call this
function you don't know size of received data, returned data is stored in
dynamic size binary string. This method is preffered for reading from
stream sockets (like TCP). It is very goot for receiving datagrams too!
(UDP protocol)}
2. Synapse RecvPacketOK. Now I see what you meant. I will look into the issue, but please note I'm not a networking expert either, I'm not familiar with all the intricacies of TCP/IP protocol. With that said, I do have a closed source project, with a similar structure as the attached demo from my previous post, which is running for years. Multiple clients communicates via the server, exchanging large amount of data, nobody ever complained about data loss.
For that I'm still not convinced. The docu I also read, and it doesn't say anything about packets, just the available data of the byte stream.
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. And I don't see that case handled in your code. The other issue I see is if one message doesn't come as one IP-packet but is split up. If the second one is delayed and RecvPacket is called before arrival, then I expect to get returned the already received data of the first IP-packet. Which is not the complete message. In both cases the FBlockSocket.LastError should be OK / zero.
The reason I looked so close into that is that I think the above issues exist and I'm not sure how to handle them efficiently. Combining partial "packets" always includes some buffering and copying. But perhaps for messages smaller than IP-packet size this is no issue?
When I made some tests and sent a "frame" combined of a byte, a word, a data block and again a byte I checked the network traffic with wireshark. Each part was sent on its own (with fClientSocket.SendBuffer) and according to Wireshark also transfered in its own IP-packet. I would have expected that at least beginning with the second portion, the code should be faster than the network and thus the data should then be transfered combined in one IP-packet. But it wasn't. Could be due to the small data sizes or implementation dependent or I just don't understand the TCP protocol correctly.
OK, I see. If it works it works :-)I am not a networking expert but I have a dozen of Synapse based tcp/ip and serial applications working 24/7 in heavy industrial environments without leaks or dropped messages. Some of them are made more then 10 years ago (with Delphi 7 and 2006) and there was no reason for any changes since commissioning deployment on Windows servers, and some of them run on Linux servers or ARM boards that do not even restart for more then a year or two and have a high traffic load.
Perhaps some networking experts around here can clarify if its safe that way.
there's no doubt that Synapse is working very well. The question was if it can be relied on that a buffer/packet sent via TCP ist received as such packet using Synapse's RecvPacket. In my understanding TCP doesn't guarantee that, but only a stream of bytes in the correct order. Just like a Serial port.Then perhaps you should switch from RecvPacket to another RecvXY(RecvByte, RecvInteger, etc...). In the end all of them rely on RecvBuffer and the low level Recv function.
Hello avra,as far as i know, UDP that is not guarantee that every packet is sent and received correctly. TCP/IP DOES guarantee that every packet is sent correctly altough packet sequence is not guaranteed. coz of this feature, many router will cut your packet if you exceded your quota. in case your packet is dropped by the router, your server will send your dropped packets again and again till download completed. on other side, UDP can not be limited, it's only option is dropped only.
there's no doubt that Synapse is working very well. The question was if it can be relied on that a buffer/packet sent via TCP ist received as such packet using Synapse's RecvPacket. In my understanding TCP doesn't guarantee that, but only a stream of bytes in the correct order. Just like a Serial port.
Would be interesting to know, how you dealt with this issue, parsing the data stream or relying on packets?
Regards~
as far as i know, UDP that is not guarantee that every packet is sent and received correctly.
TCP/IP DOES guarantee that every packet is sent correctly altough packet sequence is not guaranteed.
If you find a way to improve RecvPacket please let me know, so I can integrate it in the test application.
Packet sequence is guaranteed with TCP (at the recipient, not during transit!), otherwise communication that relies on the order of the data (e.g. file downloads) wouldn't be possible without additional protocols.As said before, my understanding of TCP is that there are no packets at all exposed to the application but only a byte stream. So your mentioned file download only works if its size is known to the receiver, otherwise it couldn't determine when the transfer is complete. Is this correct?
Packet sequence is guaranteed with TCP (at the recipient, not during transit!), otherwise communication that relies on the order of the data (e.g. file downloads) wouldn't be possible without additional protocols.As said before, my understanding of TCP is that there are no packets at all exposed to the application but only a byte stream. So your mentioned file download only works if its size is known to the receiver, otherwise it couldn't determine when the transfer is complete. Is this correct?
As said before, my understanding of TCP is that there are no packets at all exposed to the application but only a byte stream. So your mentioned file download only works if its size is known to the receiver, otherwise it couldn't determine when the transfer is complete. Is this correct?Here the word packet maybe a bit confusing, packet from your view differs by its meaning in network topic. All data traveling within TCP packets. There is no guarantee that you receive for example 3kb sent packet from the client at once, I think in most cases data checking and using Stream classes or implementing proper buffering is a must.
1. what does "broadcast" and "broadcasting" mean?Select one ore more client + right click and you will see :)
2. How can I get clients to talk to other clients and not to the server.You can't. This is not implemented. Shouldn't be to difficult to implement though.
1. TTCPServer.DisconnectClient only removes the client from the list, but it doesn't actually close the client's connection. Is this intended or is there something missing?Inside DisconnectClient, method Remove is called, where the socket is closed:
The implementation of TClientThread.Execute seems to be responsible for both receiving data from the client and sending data from the server to the client. However, when the server has data waiting to be sent to the client (which is done in ProcessTask), these data will not be sent immediately, but have a delay because the receive timeout (in RecvMessage) always has to be awaited. How can I improve this so that responses from the server to the client are sent immediately?Yes, I agree, this can be a problem. You can solve it by:
TBaseType = (btClient, btServer, btServer_AcceptedClient)You add more like btFileTransfer, btStreaming etc...For streaming you can switch to udp.
Thanks for your help.Thanks for your comments.
It might also be possible that #2 is just a misuse of your component on my side. I'm using the TTCPServer's instance's SendMessage method for responding. I'm not sure whether this is correct. In my app, I have to separate the server logic from the protocol logic. All examples I have found for servers using TBlockSocket (e.g. a chat server somewhere else in this forum) do the response directly inside the client's Execute method. Of course, this is done for simplicity of the example, and indeed this makes creating a TCP server very simple, but I feel that things quickly get rather complicate when decoupling response handling from the server and taking into account that it might take a moment to prepare the response while everything should keep responsible in the meantime and no packets must get lost.The demo project was meant more for beginners. I designed SendMessage, SendStream and SendFile as a high level functions, so the users don't have to worry about implementation details. The server logic it is separated from the protocol logic via the TTaskList. You can read more about it here: https://forum.lazarus.freepascal.org/index.php/topic,48677.msg406330.html#msg406330
so it possible without causing trouble to use a separate TBlockSocket for the sending thread? I'm asking because both the receiving and the sending thread will have to use the same ports. I don't want the clients themselves to require two threads too because this would cause incompatibilities with other tools (in my case, especially telnet-Clients must be able to connect for debugging purposes).Slowdowns may occur if both the client and server sends large files for example at the same time. As I mentioned in my previous post, i solved this issue by creating more worker threads. However this does require more threads on the client side too. I don't see how you can solve it without extra threads no matter what solution do you choose. Since I don't know any details about you project, unfortunately I cannot give you any useful information.
Overall, your server is very well designed and I hope it will work threadsafe even for a greater number of clients. I always have a some trouble in getting multithreading right, so your example has been of great value for me.Each client connection has a separate thread assigned at server side, so you shouldn't face problems even with a larger number of clients. At least in theory...again without knowing the details I cannot answer. I have a similar, not quite the same client/server application which is running for years, but I had to admit the workload on those application is relatively small.
2. The implementation of TClientThread.Execute seems to be responsible for both receiving data from the client and sending data from the server to the client. However, when the server has data waiting to be sent to the client (which is done in ProcessTask), these data will not be sent immediately, but have a delay because the receive timeout (in RecvMessage) always has to be awaited. How can I improve this so that responses from the server to the client are sent immediately?
Is it possible without causing trouble to use a separate TBlockSocket for the sending thread? I'm asking because both the receiving and the sending thread will have to use the same ports. I don't want the clients themselves to require two threads too [...].
maybe you might want to have a look on it whether the changes concord with your concepts. I tried to be as minimally invasive as possible.I will definitely check out your changes and don't worry about my concepts, feel free to modify the code in any way you like. The fact that you shared your changes it's a good thing. Thanks for that!
By the way, in the meantime I stumbled over a article that describes the issue about the assumption of packets in TCP that I stated in a message earlier in this thread:Thanks for the link, interesting article indeed.
https://www.sobyte.net/post/2021-12/whys-the-design-tcp-message-frame/
Not related to this thread, however I will update synapse in OPM soon. Is this a new release or still part of trunk? IIRC the last release was 40.1.
@kupferstecher: I had thought about setting the timeout to zero, too, but that would be equal to polling, won't it? I want to avoid this situation because it consumes CPU-time for nothing.Yes, I'd call it polling then. But the application main loop also is polling, so the overhead should be very small. And a few CPU cycles each 10ms is nearly nothing.
I have seized on the idea of GetMem using separate threads of sending and receiving. In my program I use a very slimmed-down variant of the original utcpsockets.pas, but I wanted to share the result so I have re-applied my changes to utcpsockets.pas.After quickly checking your code, my understanding is that you use the same socket for both threads, which you pass when creating the threads:
[...]
About the ports, I'd have expected that it won't work. But my tests have been positive so far: the concept seems to work. I use two separate TBlockSockets configured with the same settings so they won't interfere with each other. And because on is only sending and the other one is only receiving, there should be no conflict on the socket either. However, I haven't tested high loads yet.
I tested version 2.0.12 but unlike version 2.0.10, the client freezes, if while I send a file I go to send something else as a text message. The server receives the file but the client stops responding.Hi Phoenix,
For the test I used a file slightly larger than a gb while for the text only one word. Always reproducible.
Windows 10 64bit
Laz 2.2.4 64bit FPC 3.2.2
know that client and server are designed to run on different executables but with the version already available, is it possible to run them on the same executable? The idea would be that each exe has a chance to become server when the active server is shut down. But the exe that will have the active server does not allow you to connect the clients unfortunately.I don't see an easy way to achieve this. However you can communicate between the server and local client.
In any case version 10 for what I need is sufficient and working :).You're welcome!
Thank you
using application GUI works great,
but i am trying to create a daemon service
with the daemon service the service activates normally.
but when I connect with the client returns the error:
"Invalid username or password.(10013)"
Has anyone tried using it as a daemon service?
Can someone help me?
....
in console application the same problem happens
from what I understand is a problem with TThread, which both with daemon and console works differently compared to LCL.Windows:
@datilasQuotefrom what I understand is a problem with TThread, which both with daemon and console works differently compared to LCL.Windows:
Since windows vista(circa 2007) a service cannot interact with the desktop, meaning you cannot show forms, messages like you would from a regular application. The so called session 0 isolation was introduced for security reason. If you would like to run the server as service, you have to get rid of the visual components. This is easy because de business and UI logic are well separated. You have to move the UI logic to a standard application and communicate with the service/server via sockets, pipes, named pipes, memory mapped files, etc.
Linux:
Unfortunately I have no idea if a daemon can interact with the desktop under linux. Most likely not.
I want to put the server with service in linuxThen remove every visual component from the server and you are good to go.
and the client with a gui application
the issue is there will be no interaction with the user on the server, only on the client.
so i would like to run the server as daemon or console.
this I already did and the error of my first post occurs (Reply #40)
Then remove every visual component from the server and you are good to go.
this I already did and the error of my first post occurs (Reply #40)
"Invalid username or password.(10013)"
@datilasQuotethis I already did and the error of my first post occurs (Reply #40)
"Invalid username or password.(10013)"
Did you provide a password for the server? Something like this:
I attach a version where the server is a daemon(only tested on windows).
Hi @GetMem I tried to edit your project but I ran into a problem. In the attached application I have inserted a menu item "File > Test" on the server side to send n messages in broadcast but the client does not receive all the messages sent by the server. I made some changes in utcpsockets.pas but the already available features seem to work even with the changes.. :-\You are on the right track, protecting with CriticalSection is not enough though, you have to wait until the lock is lifted, before you can add or remove a task. The attached solution works, but is far from ideal.
ps. I used laz.VirtualTrees and disabled internal messages from usettings because the client (launched on lazarus) returned a read error when used during testing. Maybe GUI calls need to be "protected"?
Windows 10 64bit
Laz 2.2.4 64bit FPC 3.2.2
You are on the right track, protecting with CriticalSection is not enough though, you have to wait until the lock is lifted, before you can add or remove a task. The attached solution works, but is far from ideal.
PS: I'm working on a second edition...
Indeed the test works :). But trying to send a file, the client freezes (see reply #42).The pinging mechanism was also effected by your modification. Please try again, I don't see any freezing now.
Thanks and sorry for the extra work
The pinging mechanism was also effected by your modification. Please try again, I don't see any freezing now.
Ok thanks, it works almost perfectly :). It no longer freezes "permanently" so requests are all accepted. But if I send a file large enough to allow me to send a simple message, when I press "send", the client becomes unresponsive until the download to the server has finished.Please note that synapse use blocking sockets, with limited support for non-blocking mode. While you send a large file you cannot send a text in parallel, unless you spawn another worker thread both on the client end server side, just for the file transfer. I can make the client more responsive(see attachment), but the transfer won't be faster.
It seems to work fine but I don't know if there is anything else to consider..
Please note that synapse use blocking sockets, with limited support for non-blocking mode. While you send a large file you cannot send a text in parallel, unless you spawn another worker thread both on the client end server side, just for the file transfer. I can make the client more responsive(see attachment), but the transfer won't be faster.Yes, synchronicity is the strong point. The goal was just to send tasks when you want without blocking the button.
You can even complicate things by sending a large file from client to server and in the same time another large file from server to client. It won't work in parallel either in the current implementation.
The task list is not locked, one ore more task can be overwritten or deleted. Even if you manage to copy the next task in a safe way, ProcessTask won't work faster, you need extra threads.You're right, the lock in GetNextTask() is not enough because it must be maintained for the entire execution. Thank you :)
You're right, the lock in GetNextTask() is not enough because it must be maintained for the entire execution.Actually GetNextTask is safe, somehow I missed the function body. Sorry for that! What I said in my previous post still holds though, the client/server communication won't be faster.
Actually GetNextTask is safe, somehow I missed the function body. Sorry for that!It is OK. But even my answer shows that I don't know much about synapse :-[.. otherwise maybe I would have insisted more ;)
I did not test it extensively, it might contain bugs/leaks. Please test it.thanks :), the code seems to work as expected. With the previous modifications a memory leak was introduced, now I fixed it (see attachment).
PS: If you wish to improve the code, I have a few more ideas(unfortunately almost no free time).Ideas are always welcome, then for the implementation one always hopes not to be alone. I think that those who benefit from your demo can contribute in turn according to their possibilities.
Ideas are always welcome, then for the implementation one always hopes not to be alone. I think that those who benefit from your demo can contribute in turn accordingto their possibilities.Ideas:
Currently we are ping-ponging with the source files, like we did in the '90. It' s so unprofessional and dirty, I almost enjoying it. :D
1. When accessing FThreadList(TThreadList) in TTCPBase class, the following mechanism is used:Which is fine, but not enough. With the current method, if more then one client is connecting at the same time, the server might miss a few clients. Another Lock/Unlock mechanism should be implemented, similar to the one in TTaskList, using CriticalSections and the FBlocked boolean. TThreadList can be replaced with a simple TList because it will be protected with CS.
This is a bug and should be fixed.
I attach the code that hopefully solves but there are some doubts that I signaled with "#"Everything looks fine, except when two clients simultaneously disconnect and the threads are removed from the servers list. It looks to me that the first thread will lock the list and the second one will be ignored. The "If not FBlocked then ..." condition is missing. Unfortunately in this particular case it's very hard to check for FBlocked without slowing down the main thread. I still have an uncontrollable urge to rewrite the whole thing, it would be much easier this time, because I learned from my mistake.
I personally always initialize everythingGood practice! I tend to cheat and initialize only what is absolutely necessary. Most of the time I get away with it without any issues.
I still have an uncontrollable urge to rewrite the whole thing, it would be much easier this time, because I learned from my mistake.
I tend to cheat and initialize only what is absolutely necessary. Most of the time I get away with it without any issues.
Everything looks fine, except when two clients simultaneously disconnect and the threads are removed from the servers list. It looks to me that the first thread will lock the list and the second one will be ignored.