Client Server socket behavior on XP different for 127.0.0.1

[Tim]

I have two java applications, one a client, the other a server.

The cient connects to the server and then they start transmitting data
back and forth.

If I run the server on Lunix/Unix, connecting via a remote client is
not a problem. However, if I am running the server on Windows XP, it
appears that the first string sent from the server to the client that
is not terminated with a \n causes both the client and the server to
Exception out on their respective sockets. This takes several minutes
and actually hoses network access on the XP mashine, requiring a
reboot to regain net access.

If I start the client up on the same machine as the server (still
using XP) and connect via 127.0.01 instead of the actual IP address,
evertyhing works just fine.

I have checked to ensure that there is no firewalling going on, and
this behaviour has been observed on more than one XP machine.

Any help would be appreciated.

Thanks,
Tim

Client connects rather simply.

sckConnection = new Sockect(address, port);
stmOut = new DataOutputStream(sckConnection.getOutputStream();
stmIn = new BufferedReader(new
InputStreamReader(sckConnection.getInputStream()));

stmOut.writeBytes("data\n");

Server also uses DataOutputStream and BufferedReader.
Server sends commands like the following:
stmOut.writeBytes(""+(char)3+"client message\n");
stmOut.writeBytes(""+(char)14);

I get 3 messages of the first type sent to the client (along with
responses sent back to the server) but the 14 doesn't seem to make it.

Client does the following to process input:
while (incoming != -1)
{
incoming = stmIn.read();
switch (incoming)
{
case 3:
addText(stmIn.readLine()+"\n");
case 14:
blnLoaded = true;
}
}

 

[Steve Horsley]

I have two java applications, one a client, the other a server.

The cient connects to the server and then they start transmitting data
back and forth.

If I run the server on Lunix/Unix, connecting via a remote client is
not a problem. However, if I am running the server on Windows XP, it
appears that the first string sent from the server to the client that
is not terminated with a \n causes both the client and the server to
Exception out on their respective sockets. This takes several minutes
and actually hoses network access on the XP mashine, requiring a
reboot to regain net access.

If I start the client up on the same machine as the server (still
using XP) and connect via 127.0.01 instead of the actual IP address,
evertyhing works just fine.

I have checked to ensure that there is no firewalling going on, and
this behaviour has been observed on more than one XP machine.

Any help would be appreciated.

Thanks,
Tim

Client connects rather simply.

sckConnection = new Sockect(address, port);
stmOut = new DataOutputStream(sckConnection.getOutputStream();
stmIn = new BufferedReader(new
InputStreamReader(sckConnection.getInputStream()));

stmOut.writeBytes("data\n");

Server also uses DataOutputStream and BufferedReader.
Server sends commands like the following:
stmOut.writeBytes(""+(char)3+"client message\n");
stmOut.writeBytes(""+(char)14);

I get 3 messages of the first type sent to the client (along with
responses sent back to the server) but the 14 doesn't seem to make it.

Client does the following to process input:
while (incoming != -1)
{
incoming = stmIn.read();
switch (incoming)
{
case 3:
addText(stmIn.readLine()+"\n");
case 14:
blnLoaded = true;
}
}

Any data sensitivity is due entirely to your code - not the TCP stack.

Firstly, you are probably using different character set conversions
between the sender and the receiver, because DataOutputStream.writeBytes()
just takes the lower 8 bits of the character (effectively using ISO8859-1
encoding), but new InputStreamReader(InputStream) creats a Reader that uses
the platform default characterset encoding. So you cannot at the moment
be sure that the characters you send are the characters you receive.
It may be that your (char)14 is being converted to a questionmark.

Secondly, beware that TCP does not respect message boundaries - it can
split or concatenate chunks of data that are sent in separate write()
calls. This splitting and concatenating is affected by network
timing, so may behave differently locally to the same machine than
over a network. If you assume that a read() will always get exactly
what one write() sent, you will eventually go wrong.
You seem to be using explicit message boundaries here
(using '\n', '\r' or "\r\n" as the separator), but bear this
in mind for the future.

Thirdly, if you use a buffered writer, remember to call flush() at
the end.

I don't know why you would get an exception - there is nothing in
the code you posted that ever closes the connection.

I don't know why using the loopback address should change behaviour.

Steve

 

[Tim]

Any data sensitivity is due entirely to your code - not the TCP stack.

Firstly, you are probably using different character set conversions
between the sender and the receiver, because DataOutputStream.writeBytes()
just takes the lower 8 bits of the character (effectively using ISO8859-1
encoding), but new InputStreamReader(InputStream) creats a Reader that uses
the platform default characterset encoding. So you cannot at the moment
be sure that the characters you send are the characters you receive.
It may be that your (char)14 is being converted to a questionmark.

Secondly, beware that TCP does not respect message boundaries - it can
split or concatenate chunks of data that are sent in separate write()
calls. This splitting and concatenating is affected by network
timing, so may behave differently locally to the same machine than
over a network. If you assume that a read() will always get exactly
what one write() sent, you will eventually go wrong.
You seem to be using explicit message boundaries here
(using '\n', '\r' or "\r\n" as the separator), but bear this
in mind for the future.

Thirdly, if you use a buffered writer, remember to call flush() at
the end.

I don't know why you would get an exception - there is nothing in
the code you posted that ever closes the connection.

I don't know why using the loopback address should change behaviour.

Steve

Thanks for the response, here is a little more info and more questions


The error message/traceback from the server log file is as follows:
ERROR::Mon Aug 30 10:33:53 2004::thread=Thread-6::SendThread.run():0
to null::java.net.SocketException: Software caused connection abort:
socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:105)
at java.io.DataOutputStream.writeBytes(DataOutputStream.java:256)
at SendThread.run(SendThread.java:24)
at java.lang.Thread.run(Thread.java:536)

Is it possible that (char)14 would really come through as something
other than 14 when treated as a number? How could using 127.0.0.1 vs
real IP affect the char set used? Any advice on how to specify char
set in both client and server to correct this issue?

I do not think network latency is a factor, as the linux machines the
server has run on have been in Texas and California with clients
connecting from as far away as Lithuania. This issue only happens on
XP. The server gets the same exception it would get for a client
machine being unplugged from the network. And the client gets the
same error it would get if the server machine just went away. The
really odd part is that some of the messages get through. Users can
login, or create a new account, but once the password has been
entered/verified, the client gets no more messages. This points to
something in the code, but I am having trouble seeing what it is.

The complete source for client and server is available here:
http://prdownloads.sourceforge.net/duskrpg/sourceFiles.zip?download

Are you saying that
stmOut.writeBytes(""+(char)3+"client message\n");
could get split up into multiple writes? How would stmIn.readLine()
react to that? I am assuming it waits for the \n.

Thanks again for the help!
Tim