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:
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?
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().)