2009-07-29 3 views
0

У меня есть несколько узлов, действующих как серверы и клиенты, использующие сокеты TCP Java, т. Е. Socket и ServerSocket. Каждый узел использует постоянные соединения для связи с 4-10 соседями. Тем не менее, иногда узел (node1) может привести следующее исключение при попытке подключиться к другому узлу (NODE2):Java: Connection отказано, но netstat говорит иначе

java.net.ConnectException: Соединение отклонено

Если я бегу NetStat на node2, это показывает, что TCP-соединение установлено с node1 на соответствующем порту (в этом случае 61685).

ТСР 0 0 (node2): 61685 (node1): 55150 СОЗДАН

Однако node1 бросает то же исключение каждый раз, когда он пытается подключиться.

ServerSocket создается следующим образом:

void OpenRcvSocket(final int port) { 
    Thread rcvthread = new Thread() { 
      @Override 
     public void run() { 
      ServerSocket rcvlistener = null; 
      boolean running = true; 

      try { 
       rcvlistener = new ServerSocket(port); 
       while(running) { 
        Socket incoming = rcvlistener.accept(); 
        new ConnectionHandler(incoming); 
       } 
      } catch (IOException ex) { 
       System.out.println(ex); 
      } 

      finally { 
       try { 
        rcvlistener.close(); 
       } catch (IOException ex) { 
        System.out.println(ex); 
       } 
      } 
     } 
    }; 
    rcvthread.start(); 

}

Передающая часть выглядит следующим образом:

synchronized void SendMsg(String dest, Message myMsg) { 
    PrintWriter printwr = SendingConnectionList.get(dest); 
    try { 
     if(printwr == null) { 
      Socket sendsock = new Socket(dest, port); 
      printwr = new PrintWriter(sendsock.getOutputStream(), true); 
      SendingConnectionList.put(dest, printwr); 
     } 
     printwr.print(myMsg.MsgToString()); 
     printwr.flush(); 
    } catch (UnknownHostException ex) { 
     System.out.println(dest+": "+ex); 
    } catch (IOException ex) { 
     System.out.println(dest+": "+ex); 
    } 
} 

Странная вещь, что эти узлы, как правило, не отказываются от всех входящие соединения, потому что из 10 соседей 6 действительно могут подключаться, тогда как 4 отклоняются. Я сомневаюсь, что на всех узлах, которые я пробовал, есть брандмауэры, и я уверен, что служба работает на порту. Есть ли другая причина этого исключения? Благодаря!

+0

- это ваш ConnectionHandler, начинающий собственный поток? – nos

+0

Да, ConnectionHandler запускает новый поток, который продолжает проверять, было ли получено что-либо и что он должен делать с ним. – thodinc

+0

Покажите точную трассировку стека, включая указание линии, в которой происходит исключение. –

ответ

0

Возможно, вы захотите проверить файл политики безопасности java.

Default Policy File

Там может быть что-то там предотвращения вашей виртуальной машины Java с помощью порта/адреса.

+0

Дело в том, что иногда не все соединения не отменяются. Некоторым узлам удается подключиться, в то время как другие отключены. Если ни один узел не может подключиться к этому узлу, проблема может быть связана с самим блокированием узлов. Может ли быть какая-либо другая причина для исключения этого исключения? – thodinc

0

В Windows вам, возможно, придется сообщить брандмауэру Windows, чтобы позволить Java выполнять сетевую активность. Это могло быть случайно отклонено.

+0

Все узлы имеют ядро ​​Fedora 8.0, поэтому, если владельцы узлов не устанавливают сам брандмауэр, их не должно быть. На данный момент я работаю с 400 узлами, и приложение может работать примерно на 320 из них без каких-либо проблем, но вряд ли 80 узлов настроили брандмауэры, когда их не должно быть. Я отправил им электронные письма, чтобы узнать, так ли это, но есть ли другие причины, которые могут произойти, тем более что netstat показывает статус ESTABLISHED? – thodinc

+0

В этом случае я бы тщательно исследовал, если процесс может не прослушиваться на всех сетевых интерфейсах, а только в одном. –

+0

Спасибо за ваш ответ. Узлы должны иметь идентичные конфигурации оборудования, а те немногие, что я проверил, имеют только один интерфейс Ethernet, loopback и интерфейс крана. – thodinc