Re: Client-Server application (based on sockets) - too many messages at the same time
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Sat, 02 Jun 2007 11:39:33 -0700
On Sat, 02 Jun 2007 03:22:52 -0700, Cichy <cichy83@xxxxxxxxx> wrote:
Yes, You we're right that I'm using TCP Protocol. I thought that when
I'm sending some datas over a socket it's checking how many bytes
we're sent and received.
Define "checking". In one sense, I suppose it is...after all, assuming nothing's wrong with the connection, the bytes all do eventually get sent and received. The "how many" is "checked" in that sense.
However, TCP doesn't do anything to ensure that between the first byte sent and the last byte sent, that everything received is grouped exactly the same way that it was sent.
I really was sure that there is some sort of byte (like EOM - End Of
Message, like EOF in files) which idnicates if everything was sent.
There's definitely nothing like that. You put a byte in at one end, that byte comes out at the other. Nothing more, nothing less.
But know I'm not too sure where should I check this things?
You need to look at the return value for Socket.EndReceive() and Socket.EndSend(). These are integers that tell you how many bytes were actually successfully received or sent.
When sending it looks more simple, I have a method:
public void OnSend(IAsyncResult ar)
{
try
{
Socket client = (Socket)ar.AsyncState;
client.EndSend(ar);
}
catch (Exception ex)
{
if (eerrorOccured != null)
eerrorOccured(this, ex.Message);
}
}
and probably here i can check how many bytes where sent (probably I
have to add second parameter with message to be able to resend some
bytes).
You need to hang on to the original send buffer, presumably in some per-client data structure. Along with that, you need to keep track of how many bytes in the buffer have already been sent, so that when you call Socket.EndSend(), you can compare the byte count with how many you had left to send, and if the sent bytes are fewer than the amount you actually have to send, make another attempt to send the remaining bytes.
But where should I check if i received all bytes (and the more
important questions, how could I know how many of them should
be ???).
Yes, that is the more important question. Your protocol needs to define a way for the recipient of the data to know how large that data is, so that it can tell whether it's received it all or not. How this is done depends entirely on the protocol.
Some precede the data with a byte count (which itself has a predefined way to know its length, whether that's because it's a fixed-size variable, or the byte count is sent as a string, or something like that). Some rely on something specific about the data itself; for example, strings that are always null-terminated. Some use fixed-sized structures so that every "message" is always the same size. And some even only allow for a single "message" to be sent on a given connection; once a complete "message" has been sent, the connection is closed (I'm not suggesting this is appropriate for your design...just that it's an example of how some other protocols work).
What you will do is entirely up to you, assuming you have defined your own application-level protocol (which it appears you have). But you do need to include something in your protocol so that the recipient knows when it has received a complete "message".
And also, is this construction doesn't fix the problem of receiving
only a part of a message:
clientSocket.EndReceive(ar);
I'm sorry, I don't understand the above sentence.
Pete
.
- References:
- Prev by Date: Re: Find directory of .exe (it is not always the current directory)
- Next by Date: Re: Want form to show changing data. But it could be closed, or closing, during update.
- Previous by thread: Re: Client-Server application (based on sockets) - too many messages at the same time
- Next by thread: AlgorithmNeeded
- Index(es):
Relevant Pages
|
