• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Wierd Socket Behavior

 
Ranch Hand
Posts: 246
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm trying to understand how sockets work, and having trouble. My code on my server (machine 10.72.77.49) 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:

inStream.read( { 0, 65, 0, 66, 0, 0 }, 0, 6) == 5.
Read in: "AB".
inStream.read( { 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:

inStream.read( { 0, 65, 0, 66, 0, 67 }, 0, 6) == 6.
inStream.read( { 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 <inStream.read()> 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
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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().)

 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic