Problem with application involving client/server interaction

[Madhumati]

I want to create a small application that will send some info over the network.

My problem: When the client must log into the server, it will be sending some information to the client, this is done by sending short texts to the client. But if the server only be pouring in with these little texts client fails to capture all the information. I therefore want to have the client to say that it is ready to receive the next text. Is it possible to get the server to do this? The thread got to be paused or something similar before the next prompt is sent. Can a line waiting for something to happen before it continues? For example, for a loop or similar.

This was a very strange explanation, I hope some of you get something out of this. Its grateful for any responses that may contribute to the problem solved

[HiSpeed]

What do you mean by that?

TCP already has flow control built in the protocol, so if you use a correct TCP implementation, such System.Net.Sockets.TcpClient, at both ends, it is already in order. And it is not possible to write faster than the receiver can read. Read/Write operations will block when the data is sent/read correctly, or throw exception if something goes wrong.

[Madhumati]

Yes, I am using System.Net.Sockets.TcpClient at both ends, then does it means that the client receives all the data correctly.

If you look at the code that I linked to above you can see that the client sends the data it receives from the server to a new thread (MessageReceived) where I have added quite a bit codes, for example, save as a text message received. this will then be a bottle cork that this thread does not have time to perform all functions missions before being asked to do it again?

This can be solved by MessageReceived sends the data to a background worker or like that stores files on the local disk instead of the MessageReceived to do it?

[HiSpeed]

You do not do anything, no matter how long it takes for the client.

Transport layer (TCP Protocol) takes care of throttling of the broadcast, it is not possible to send "too much" or "too fast" over such a connection. If it goes too slow on the client, than that indicates the read-TCPClient buffer is full, and it says by itself from the receiver that it can not accept more, I keep it again. It is built into the TCP protocol and not something we programmer himself.

I think you misunderstand how little TCPClient works. Data can be received at any time when the connection is opened, then placed them in the input buffer when something arrives. No Read() method receives data directly over the network, it only reads from the next buffer. Since we are using TCP, we are then guaranteed that the next we read from the buffer is always correct, complete and in order.

[Madhumati]

The lines are sent for example:

/Message|sender|message

these lines are divided by string.spilt command

I have occasionally noticed that the lines hang together when things are sent too fast when it goes like this:

/Message|sender|message/Message|sender|message

It may be because they come on the same line and that the split command only sees the start of the line and not read the last part of the line?

That is the message appears, but the user will not be shown the last post. If this is what is wrong, does anyone have a good explanation of how this can be changed?

[HiSpeed]

It seems that you will have to create the 1:1 ratio that is sent with write() on the one hand, and it is read with read() on the other?

So it is not, although it may seem that way when we test in controlled conditions. In practice, you can never trust that it is so, the underlying network protocols can divide up your packages and put them together as they wish. It looks like you read everything in the buffer and then assume that there is one and only one message. It can be both more messages, and parts of reports of them have been divided on the way and only the first part is reached.

The client must divide up the flow of certain messages.