File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Sockets and Internet Protocols and the fly likes Wierd Socket Behavior Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Sockets and Internet Protocols
Bookmark "Wierd Socket Behavior" Watch "Wierd Socket Behavior" New topic

Wierd Socket Behavior

Kevin Simonson
Ranch Hand

Joined: Oct 22, 2011
Posts: 126
I'm trying to understand how sockets work, and having trouble. My code on my server (machine is:

and my code on my client is:

Regardless of what I'm doing on my server, on my client I always execute "java RcvStrng 2". If first I execute on my server "java SndStrng AB DE" I get output:

stOs.write( { 0, 65, 0, 66, 0, 0 }, 0, 5);
stOs.write( { 0, 68, 0, 69, 0, 0 }, 0, 5);

and on my client I get: { 0, 65, 0, 66, 0, 0 }, 0, 6) == 5.
Read in: "AB". { 0, 68, 0, 69, 0, 0 }, 0, 6) == 5.
Read in: "DE".
Took 140 ms.

This is what I want, because my goal is to enter two strings on a command line on my server, disassemble it into individual <byte>s, send it over the socket, and reassemble it into the original pair of strings on the client.

Now when on the server I execute "java SndStrng ABC DE" I get output:

stOs.write( { 0, 65, 0, 66, 0, 67 }, 0, 6);
stOs.write( { 0, 65, 0, 66, 0, 67 }, 0, 1);
stOs.write( { 0, 68, 0, 69, 0, 67 }, 0, 5);

which again is what I want; the single byte sent on the second line is just a signal to my client that the string started with the first write has ended.

But then the output I get on my client is: { 0, 65, 0, 66, 0, 67 }, 0, 6) == 6. { 0, 0, 68, 0, 69, 0 }, 0, 6) == 6.
Took 240 ms.

So the single byte my server sends to signal the end of string "ABC" is getting added into the first string. If my server can call <stOs.write()> on a <char> array and specify five significant bytes being sent, and my client can read that information and interpret it correctly, then when my server calls <stOs.write()> on a <char> array and specifies one significant byte being sent, why doesn't the <> on my client return a one? Why the different behavior if five bytes are being sent across from the behavior when one byte is being sent across?

Kevin Simonson
Jeff Verdegan

Joined: Jan 03, 2004
Posts: 6109

I'm not sure if I completely understand your problem, but if it's what I think it is, then it appears that you're assuming that there's a one-to-one correspondence write() calls and read() calls, when in fact, there's not.

So, for instance, if your server calls

The first read() call on your client could get just X, or XY, or XYZ. There's no correlation between how bytes are grouped into write() calls and how they'll end up grouped in read() calls. This is because TCP is stream based, not message based.

Due to buffer sizes, timing, or other coincidental issues, you may sometimes see three consecutive read() calls get X, Y, and Z just as you sent them, but that's all it is--coincidence.

(Note, though, that the +order+ will of course be preserved, just not the grouping of which bytes are in which calls to write()/read().)

I agree. Here's the link:
subject: Wierd Socket Behavior
It's not a secret anymore!