data lost issue using sockets

[korcs]

Hi,

I have an interesting issue with socket programming.

I would like to send String based information via Sockets.

As it could happen, that a part of the information gets lost on its
way to the client, I would like to send before all such packages the
size of the package as a "short" value (or something equal, but not
string because you can never be sure that your string completely
arrived ).

Does anybody know what is an elegant solution for this problem?

I send the strings using:

PrintWriter out = new PrintWriter(client.getOutputStream(), true);
out.println("test");

Thanks,

korcs

 

[Gordon Beaton]

I would like to send String based information via Sockets.

As it could happen, that a part of the information gets lost on its
way to the client, I would like to send before all such packages the
size of the package as a "short" value (or something equal, but not
string because you can never be sure that your string completely
arrived ).

Does anybody know what is an elegant solution for this problem?

TCP is - by design - a reliable protocol. If TCP fails, you will lose
the socket connection.

What is this data loss you are imagining? Have you ever *really*
experienced it? Perhaps it's a problem in the application itself?

One reason you might want to prefix each message with its size is to
help the receiver know where one message in the stream ends and the
next one starts.

/gordon

--

 

[derek]

As it could happen, that a part of the information gets lost on

its
way to the client, I would like to send before all such packages > the
size of the package as a "short" value (or something equal, but
not
string because you can never be sure that your string completely
arrived ).

You should investigate why you are "losing" data first. Instead
of trying to put some custom checks of your own in there.
Tcp should be doing that for you. If you are "losing" data, then
you will proably "lose" some of your custom checks too, then
are you going to add more custom checks for your custom checks?

Try explaining how you are "losing" your data first.

 

[korcs]

You should investigate why you are "losing" data first. Instead
of trying to put some custom checks of your own in there.
Tcp should be doing that for you. If you are "losing" data, then
you will proably "lose" some of your custom checks too, then
are you going to add more custom checks for your custom checks?

Try explaining how you are "losing" your data first.

I send an xml structure to a client.

This structure has of course an opening and an ending tag but the body
of the xml structure can have different lengths.

So I thought it is better to make sure that the client side knows in
advance, which size it should receive and if there was some bug during
the data transfer to know that the received xml struct is too big or
too small.

 

[derek]

If that is all you are sending, then dont bother with telling the other side how big it is. You could just close the socket on your end when you are done. The other end will read the data until no more data is available then process it. If there is more data after the xml, then you do need to have some agreement by which you both know where one piece of data ends and one starts. Either preface it with a length as you originally stated, or you could use a special character to signify the end of one data and the beginning of another. The choice between the two options would depend on the type of data you are sending. If you decide to use a special character, just make sure that it doesnt class with the actual data you are sending.

 

[Roedy Green]

As it could happen, that a part of the information gets lost on its
way to the client, I would like to send before all such packages the
size of the package as a "short" value (or something equal, but not
string because you can never be sure that your string completely
arrived ).

TCP/IP guaranteed accurate delivery through checksums and packet
resends.

If you used a DataInputStream you could use writeUTF which prepends
each string with a 16-bit length field. see
http://mindprod.com/jgloss/jgloss/utf.html#WRITEUTF

You could prepend each field with the 32-bit length in bytes after
encoding. If you start reading the string as a byte array, TCP will
automatically block till the whole thing is available.
See http://mindprod.com/jgloss/encoding.html

 

[Filip Larsen]

I would like to send String based information via Sockets.

As it could happen, that a part of the information gets lost on its
way to the client, I would like to send before all such packages the
size of the package as a "short" value (or something equal, but not
string because you can never be sure that your string completely
arrived ).

You don't mention how you read the data back in, but a common mistake
that gives the behaviour you seem to observe, is to fail to read the
socket in a loop until all expected data has been read (like getting end
of file or n bytes or characters) as most Java input read methods do not
guarantee that they will read "the full block" like some of the
readFully methods do. For instance, this apply when using a Reader
subclass to read data into a character array.


Regards,