Wierd problems with sockets

[Pep]

I use the following code to provide the socket communications for a
client/server application. At this point the main thread has accepted a
client socket connecti0on over the server socket and has spawned a client
thread that services the request via this code.

=========================================================================
try
{
pw = new PrintWriter(clientSocket.getOutputStream(),true); // get the
clients output stream
br = new BufferedReader(new
InputStreamReader(clientSocket.getInputStream())); // get the client input
stream
String jsonPacket = br.readLine(); // read JSON packet from client
processJSON(jsonPacket); // process the JSON request packet
pw.close(); // close the clients output stream
br.close(); // close the clients input stream
}
catch (Throwable e)
{
System.out.println("Error " + e.getMessage());
e.printStackTrace();
}
=========================================================================

So if I connect to this server application using telnet I get an instant
response from the above code. However, if I connect to this code from a C++
application using berkley sockets, I get an instant connection but have
seen from well placed prinln statements after the creation of the pw and br
streams that the actual reading takes around 181 seconds!

What could be the reason for this lag in the C++ originated communications
compared to the instant telnet origibated communications response?

TIA,
Pep.

 

[Thomas Hawtin]

try
{
pw = new PrintWriter(clientSocket.getOutputStream(),true); // get the
clients output stream

You are using the platform default character set/encoding here, which
might be EBCDIC. Best specify what you actually once.

br = new BufferedReader(new
InputStreamReader(clientSocket.getInputStream())); // get the client input
stream
String jsonPacket = br.readLine(); // read JSON packet from client
processJSON(jsonPacket); // process the JSON request packet
pw.close(); // close the clients output stream
br.close(); // close the clients input stream

These two lines will actually close the socket too.

I hope you wrap all this in a try/finally to make sure the socket really
is closed, no matter the outcome.

So if I connect to this server application using telnet I get an instant
response from the above code. However, if I connect to this code from a C++
application using berkley sockets, I get an instant connection but have
seen from well placed prinln statements after the creation of the pw and br
streams that the actual reading takes around 181 seconds!

And what if your telnet program is written in C++? An odd thing telnet
might be doing is sending telnet negotiations (I can't remember exactly
how that sequence starts). Try nc instead of telnet. Perhaps get the C++
program to send the same bytes before trying to read.

The only delays like this I can think of are from attempting DNS lookup
without a functioning DNS server. A dropped packet could give you a four
minute delay, IIRC.

Tom Hawtin

 

[Roedy Green]

What could be the reason for this lag in the C++ originated communications
compared to the instant telnet origibated communications response?

Any time you have buffering, you often have problem with the reader
sitting waiting for something stuck in the buffer. Try a flush.

 

[Pep]

You are using the platform default character set/encoding here, which
might be EBCDIC. Best specify what you actually once.


These two lines will actually close the socket too.

I hope you wrap all this in a try/finally to make sure the socket really
is closed, no matter the outcome.

Yep this is a snippet but the complete code does catch all at the end.

And what if your telnet program is written in C++? An odd thing telnet
might be doing is sending telnet negotiations (I can't remember exactly
how that sequence starts). Try nc instead of telnet. Perhaps get the C++
program to send the same bytes before trying to read.

The only delays like this I can think of are from attempting DNS lookup
without a functioning DNS server. A dropped packet could give you a four
minute delay, IIRC.

Tom Hawtin

Now this is getting really frustrating for me as I have now written very
short java application that simply opens a socket to the same java server
code and sends a message which is read in immediately.

So there is definitely something strange going on here.

If I send a message via a C++ socket to a C++ socket server it works as
expected.

If I send a message via a java socket to a java socket server it works as
expected.

If I send a message via a java client to a C++ socket server it works as
expected.

However if I send a message via a C++ socket to a java socket server it ends
up with a 3 minute delay!

I do not see that it can be a DNS problem because the debugging statements I
have in the java socket server show that the connection is made instantly.
It is the reading of the data across the socket that is causing the
problems.

Is it possible that it is the buffered reader or input stream that is
blocking because a java socket attaches something extra to a message that I
am not doing in C++, such as you intimate in your query about telnet?

Cheers,
Pep.

 

[Pep]

Thomas Hawtin wrote:

So that last little piece of the conversation between us set me off to try a
quickie and it worked!

It turns out that I need to append a "\n" in my C++ code to the socket in
order to get the java socket server to read the packet immediately.

The C++ server I originally wrote does not expect a "\n" and so the original
C++ client I wrote does not append one. However the new server I have
written in Java expects one and will block until it gets one or the timeout
expires.

Obviously the Java client socket appends a "\n" to the message it sends.

Differences in programming languages can be quite fun at times, frustrating
but fun

Thanks very much for you help in this, it's been nice talking to you,
Pep.

 

[E.J. Pitt]

Obviously the Java client socket appends a "\n" to the message it sends.

No it certainly does not.

Obviously PrintWriter.println() appends a "\n"; obviously
BufferedReader.readLine() blocks until it gets a newline; and obviously
your C++ code does not append or expect newlines.