Client can't read
-
when I connect multiple client to the server , the client can't read the data I want it to read. So if I connect two clients , the first client goes to blocking mode and the second client works a bit properly.
client code:
server code:
client can't read the incoming data from server continuously.
what should be done ? -
when I connect multiple client to the server , the client can't read the data I want it to read. So if I connect two clients , the first client goes to blocking mode and the second client works a bit properly.
client code:
server code:
client can't read the incoming data from server continuously.
what should be done ? -
You need to show your code where you access your clients and also the server side.
-
What is your actual problem? Please redescribe.
At first I thought that you have problems with parallel reading. However, the end of your initial post reads a bit different.
Looking at your code you anticipate to all at once. That is typically not possible, but for really small chunks. You will receive already a readyRead signal before all the data arrived. Therefore, when the signal trigegrs a slot routine, only a part has been received when the comms takes longer. Your readAll will beable to retrieve only what is available at that particular moment, since it does not have crystal ball and can know how much is all.
Therefore, with socket comms you often need to make some reporting around. E.g. tell first how many bytes you send and possibly other stuff. -
What is your actual problem? Please redescribe.
At first I thought that you have problems with parallel reading. However, the end of your initial post reads a bit different.
Looking at your code you anticipate to all at once. That is typically not possible, but for really small chunks. You will receive already a readyRead signal before all the data arrived. Therefore, when the signal trigegrs a slot routine, only a part has been received when the comms takes longer. Your readAll will beable to retrieve only what is available at that particular moment, since it does not have crystal ball and can know how much is all.
Therefore, with socket comms you often need to make some reporting around. E.g. tell first how many bytes you send and possibly other stuff.@koahnig I want my thread to work parallel with the main thread. in client code: I want my read function from thread and code which takes the userinput (after thread->start() command)to work at the same time without blocking one another.Current situation is that the read() function of thread doesn't work until it gets the user input.
here is output of this code: left side is SERVER and right side is CLIENT output
-
@koahnig I want my thread to work parallel with the main thread. in client code: I want my read function from thread and code which takes the userinput (after thread->start() command)to work at the same time without blocking one another.Current situation is that the read() function of thread doesn't work until it gets the user input.
here is output of this code: left side is SERVER and right side is CLIENT output
You should check the Network examples.Personally I like/used the Fortune Server and the Fortune Client examples. They give you a good starting point for experimenting.
There is no need to have extra threading for your comms here. In most cases the implementations of TcpSocket and TcpServer handles this sufficiently. I have implemented a TcpServer redistribution of information retrieved from a Tcp Socket. In a test program I have used 2 Tcp servers and 2 tcp clients communicating criss-crossing and nothing was lost.
The problem is probably the signal-slot handling in your app. Most likely nothing is blocked, but you do not receive another signal, since you are still in the slot routine.
For instance the readyRead may be triggered with the first byte, when you are in the slot routine you can read already 10 byte, but there are still some bytes arriving until the functionality in the routine is finished. For longer incoming byte streams this is often not seen until the end, when a couple of bytes are missing.
You can check bytesAvailable at the end of your routine and read teh rest when it is already in the buffer. However, beware that the is a danger with using bytesAvailable until nothing comes in anymore. For transmission with large amounts of data, you are actually blocking then.
Once again have a look to the network examples. They give you already a lot of hints.
-
You should check the Network examples.Personally I like/used the Fortune Server and the Fortune Client examples. They give you a good starting point for experimenting.
There is no need to have extra threading for your comms here. In most cases the implementations of TcpSocket and TcpServer handles this sufficiently. I have implemented a TcpServer redistribution of information retrieved from a Tcp Socket. In a test program I have used 2 Tcp servers and 2 tcp clients communicating criss-crossing and nothing was lost.
The problem is probably the signal-slot handling in your app. Most likely nothing is blocked, but you do not receive another signal, since you are still in the slot routine.
For instance the readyRead may be triggered with the first byte, when you are in the slot routine you can read already 10 byte, but there are still some bytes arriving until the functionality in the routine is finished. For longer incoming byte streams this is often not seen until the end, when a couple of bytes are missing.
You can check bytesAvailable at the end of your routine and read teh rest when it is already in the buffer. However, beware that the is a danger with using bytesAvailable until nothing comes in anymore. For transmission with large amounts of data, you are actually blocking then.
Once again have a look to the network examples. They give you already a lot of hints.