Wierd problems with sockets

Discussion in 'Java' started by Pep, Sep 9, 2005.

  1. Pep

    Pep Guest

    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.
    Pep, Sep 9, 2005
    #1
    1. Advertising

  2. Pep wrote:
    > 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
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, Sep 9, 2005
    #2
    1. Advertising

  3. Pep

    Roedy Green Guest

    On Fri, 09 Sep 2005 12:43:38 +0100, Pep <> wrote or
    quoted :

    >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.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
    Roedy Green, Sep 9, 2005
    #3
  4. Pep

    Pep Guest

    Thomas Hawtin wrote:

    > Pep wrote:
    >> 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.
    >


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

    >> 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


    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, Sep 11, 2005
    #4
  5. Pep

    Pep Guest

    Pep wrote:

    > 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.
    Pep, Sep 11, 2005
    #5
  6. Pep

    E.J. Pitt Guest

    Pep wrote:
    > 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.
    E.J. Pitt, Sep 12, 2005
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. E

    Wierd https/http problems

    E, Nov 28, 2005, in forum: ASP .Net
    Replies:
    3
    Views:
    448
  2. Replies:
    0
    Views:
    288
  3. Nobody

    Re: Problems with sockets

    Nobody, Aug 27, 2009, in forum: C Programming
    Replies:
    3
    Views:
    386
    Sri Harsha Dandibhotla
    Aug 28, 2009
  4. GilNajera

    problems with windows sockets

    GilNajera, Jan 14, 2011, in forum: C Programming
    Replies:
    5
    Views:
    356
    Michael Angelo Ravera
    Jan 18, 2011
  5. Chris Harpum

    wierd problems with Win32API and dlls

    Chris Harpum, Jun 20, 2008, in forum: Ruby
    Replies:
    0
    Views:
    82
    Chris Harpum
    Jun 20, 2008
Loading...

Share This Page