Commons Net
  1. Commons Net
  2. NET-350

"java.net.SocketException: Broken pipe" when calling "TelnetClient.sendAYT()"

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2
    • Fix Version/s: 3.0
    • Component/s: Telnet
    • Labels:
      None
    • Environment:

      Ubuntu 10.10 (x32)
      Java JDK 1.6.0.22

      Description

      I'm trying to write some code to have a reliable way to determine if a telnet connection is still available and not closed on the remote server. Even though I first call TelnetClient.isConnected(), the followed TelnetClient.sendAYT() gives me SocketException. The problem occurs when I provide invalid login credentials on purpose when logging in to the telnet server.

      Code snippet:

          private boolean isConnected() {
              return isConnected(100);
          }
      
          private boolean isConnected(int timeOut) {
              boolean connected = false;
      
              if (telnetClient.isConnected()) {
                  try {
                      connected = telnetClient.sendAYT(timeOut);
                  } catch (IOException ex) {
                      Logger.getLogger(ForceLogin.class.getName()).log(Level.SEVERE, null, ex);
                  } catch (IllegalArgumentException ex) {
                      Logger.getLogger(ForceLogin.class.getName()).log(Level.SEVERE, null, ex);
                  } catch (InterruptedException ex) {
                      Logger.getLogger(ForceLogin.class.getName()).log(Level.SEVERE, null, ex);
                  }
              }
              
              System.out.println("Still connected? " + connected);
      
              return connected;
          }
      

      What I do is execute the following:

      succesfulLogin = forceLogin.isConnected();
      
      if (succesfulLogin) {
              succesfulLogin = forceLogin.isConnected(1000);
      }
      

      When I try to fail the telnet login (providing invalid credentials), the first "isConnected()" call sometimes gives me TRUE, sometimes gives me FALSE. When it's TRUE I want to make sure that we are really still connected using a longer "TelnetClient.sendAYT()" timeout. This is where the exception occurs.

      Resulting exception:

      16-Jan-2011 16:44:04 force.ForceLogin isConnected
      SEVERE: null
      java.net.SocketException: Broken pipe
              at java.net.SocketOutputStream.socketWrite0(Native Method)
              at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
              at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
              at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
              at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
              at org.apache.commons.net.telnet.Telnet._sendAYT(Telnet.java:1095)
              at org.apache.commons.net.telnet.TelnetClient.sendAYT(TelnetClient.java:206)
              at force.ForceLogin.isConnected(ForceLogin.java:95)
              at force.ForceLogin.main(ForceLogin.java:160)
      
      1. sockclient-isconn.diff
        1 kB
        Bogdan Drozdowski

        Activity

        Hide
        Sebb added a comment -

        Thanks for the patch.

        It seemed wrong to change the existing isConnected() method, so the checks were added as a new isAvailable() method.

        Show
        Sebb added a comment - Thanks for the patch. It seemed wrong to change the existing isConnected() method, so the checks were added as a new isAvailable() method.
        Hide
        Age Bosma added a comment -

        Thanks for your reply and patch. This should at least provide a more stable check to some extend.

        While writing and wait for the exception does the trick in the end, I would have preferred a 'cleaner' solution, not depending on something to just go wrong after an arbitrary time span. Though I guess there's not really any other way.

        Show
        Age Bosma added a comment - Thanks for your reply and patch. This should at least provide a more stable check to some extend. While writing and wait for the exception does the trick in the end, I would have preferred a 'cleaner' solution, not depending on something to just go wrong after an arbitrary time span. Though I guess there's not really any other way.
        Hide
        Bogdan Drozdowski added a comment -

        Try my patch - it introduces more tests that check if the Socket is connected. But the only guaranteed way to theck the connection state is to actually use the socket. If reading or writing throws an Exception, we know we're not connected, and this is exactly what you're doing. SocketClient can't perform and read or writes, because it would eat bytes that the cliane was waiting for or perform unspecified actions on the server. You're checking the right way and you should continue doing it this way. The patch MAY solve something, but on the other hand, it may not. No guarantee. Keep using your method (writing and testing for I/O exceptions).

        Show
        Bogdan Drozdowski added a comment - Try my patch - it introduces more tests that check if the Socket is connected. But the only guaranteed way to theck the connection state is to actually use the socket. If reading or writing throws an Exception, we know we're not connected, and this is exactly what you're doing. SocketClient can't perform and read or writes, because it would eat bytes that the cliane was waiting for or perform unspecified actions on the server. You're checking the right way and you should continue doing it this way. The patch MAY solve something, but on the other hand, it may not. No guarantee. Keep using your method (writing and testing for I/O exceptions).

          People

          • Assignee:
            Unassigned
            Reporter:
            Age Bosma
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development