socket connected??

Discussion in 'Java' started by manuel aldana, May 4, 2004.

  1. i wrote a program where a client socket communicates with a server
    socket in just one direction (i.e. i only use a server input stream from
    a client).

    apart from getting an IOException when writing to streams how do i know
    from the view of the server that the client socket isn't running anymore
    (shutdown from winXP or unplugging ethernet cable etc. etc.)?
    tried to figure that out from catching other exception but no success.
    no success in using Socket.isConnected() either. it seems to just test
    if it was connected at the beginning.

    maybe it is the only solution to establish another stream, where the
    server pings the client every 10 seconds to know if it's still there??

    thnx in advance!
    manuel aldana, May 4, 2004
    1. Advertisements

  2. Because of the nature of the socket protocol, there is no way to determine
    if a particular socket is working unless you actually try it out. Because
    packets may take different routes it is even possible (though highly
    unlikely) for a second socket to report ok while your main one fails.
    Pretty much everyone that codes a custom TCP/IP protocol includes an "are
    you there" embedded request/response. Of course, when it comes right down
    to it, having received an "are you there" reply is no guarantee that the
    server will still be available even on the next immediate request. Every
    message sent is an implicit test for connectedness that is confirmed by
    receiving the reply.

    Matt Humphrey
    Matt Humphrey, May 4, 2004
    1. Advertisements

  3. implements the TCP transport layer. thought with TCP the
    packages always use the same route?

    seems that there is no java-method to simply check my requirement. i
    think i just implement a ping from server to client to check if it is
    still there.

    thanks for the answer!
    manuel aldana, May 4, 2004
  4. First, it would be a *different* TCP connection. Second, TCP has nothing
    whatsoever to do with routing, that's what IP does. And having alternative
    routes is a major feature of IP.

    BTW, the TCP standard already does what you want via the SO_KEEPALIVE
    option; unfortunately, the standard does not include setting the
    keepalive interval, and neither does, apparently, Sun's implementation.
    Michael Borgwardt, May 4, 2004
  5. I agree with everything else you said. Just a minor note: sun does not
    implement tcp, it just uses it. The OS implements tcp

    Manolis Wallace
    Image, Video & Multimedia Systems Laboratory
    Department of Computer Science
    School of Electrical & Computer Engineering
    National Technical University of Athens
    Manolis Wallace, May 4, 2004
  6. manuel aldana

    Mason Bryant Guest

    Mason Bryant, May 4, 2004
  7. Timeout only occurs when there is a blocking operation being done.
    There is no timeout when both sides of the connection are silent.
    Michael Borgwardt, May 5, 2004
  8. thanks, i did it this way yesterday already and it works.
    before my questions, i thought that there is always a execption in
    read() thrown when the client passes away. now i understood the meaning
    of tcp much better.
    manuel aldana, May 5, 2004
  9. There is no way to know the connection is broken until you try to
    write something. Then the TCP stack can eventually decide that the
    connection is broken if it never gets an acknowlegement of that
    sent data. But if you don't send something, you cannot know the
    other end has gone away. It's like wanting to know if someone is
    still on the other end of the phone but without either of you
    speaking. It can't be done.

    A sender can always detect a broken connection by sending data -
    the TCP stack notices the lack of a TCP ACK and reports the

    A silent listener may never discover a broken connection though.

    Some kind of application-level keepalive message might be a solution.
    Oddly, the application need only periodically send messages that the
    application at the other end will ignore. This is enough to trigger
    an IOException on write() eventually.

    You are right, isConnected() only tells you if the socket ever was
    connected - it doesn't return false after a disconnect.
    Opening another stream won't tell you anything of interest about this

    Steve Horsley, May 5, 2004
  10. manuel aldana

    Roedy Green Guest

    What you can do is send a dummy heart beat packet every X seconds if
    there is no other traffic. Then when you die on read timeout, you
    know there is real trouble, not just nothing to say.

    TCP/IP is quite different from modem traffic. There is no carrier to
    your destination when nothing is being said. It is just a silent
    absence of packets. So you can't really tell if the other end has gone
    away until you probe them. Someone said TCP/IP now has an ability to
    automatically send dummy heartbeat packets to detect disconnect
    sooner. I don't know what you do to turn it on, or control the probe
    frequency. Your app would be unaware of them.

    This is the technique I use in Harvest and CyberView Plus.

    Other "heartbeat" like packets are" "request shutdown" to tell the
    other end to save, etc to close up shop gracefully, and "shutdown" to
    acknowledge the request and say it is all clear to close the socket.
    Roedy Green, May 6, 2004
  11. RFC 1122 ain't exactly new. Actually now that I checked it, I see that
    it's not a required feature.
    Java allows you to turn it on via Socket.setKeepAlive(). Unfortunately,
    it does not allow you to set the frequency, which makes it rather useless.
    I suppose you'd get a SocketException somewhere if there is no answer.
    Michael Borgwardt, May 6, 2004
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.