Skip to main content

Unexpectedly disconnection from RDV peer

2 replies [Last post]
sergeya
Offline
Joined: 2007-08-17

Hi all
I’m using TCP transport on my rendezvous peer (server + client) and tcp only client on edge peers. for being able to communicate with each other my edge must be connected to Rendezvous peer. But sometime I see what my peers unexpectedly disconnected from RDV and connect back in 20 sec - 2 min.
How I can made this connection stable? What I should additionally investigate? Do you know any possible reasons of this behaviour

I have turned on tcp log and see a lot of the following errors :

DEBUG 2007-08-30 07:47:19,571 {ThreadedMessenger for jxta://uuid-88ACED5024B848F3B5BECC426A5BE499A77B5EE85DE74EBD9BCEF0FF40EC6F6603} TcpConnection - Sent net.jxta.endpoint.Message@30696613(3){18470,18469,18466,18465} successfully via 195.5.36.242:1540
INFO 2007-08-30 07:47:24,018 {TCP receive : urn:jxta:uuid-88ACED5024B848F3B5BECC426A5BE499A77B5EE85DE74EBD9BCEF0FF40EC6F6603 on address tcp://0.0.0.0:0} TcpConnection - tcp receive - Connection was closed by 195.5.36.242:4981
INFO 2007-08-30 07:47:24,018 {TCP receive : urn:jxta:uuid-88ACED5024B848F3B5BECC426A5BE499A77B5EE85DE74EBD9BCEF0FF40EC6F6603 on address tcp://0.0.0.0:0} TcpConnection - Failure close (open 3455408ms) of socket to : tcp://0.0.0.0:0 / 195.5.36.242:4981
DEBUG 2007-08-30 07:47:24,018 {TCP receive : urn:jxta:uuid-88ACED5024B848F3B5BECC426A5BE499A77B5EE85DE74EBD9BCEF0FF40EC6F6603 on address tcp://0.0.0.0:0} TcpConnection - stack trace
java.lang.Throwable: stack trace
at net.jxta.impl.endpoint.tcp.TcpConnection.close(TcpConnection.java:696)
at net.jxta.impl.endpoint.tcp.TcpConnection.run(TcpConnection.java:640)

or
DEBUG 2007-08-30 05:18:56,752 {ThreadedMessenger for jxta://uuid-88ACED5024B848F3B5BECC426A5BE4997A9F7D7482B3422A9CE39D622B54C51403} TcpConnection - Sending net.jxta.endpoint.Message@21684929(4){404} (1805) to tcp://0.0.0.0:0 via 195.5.36.242:3508
DEBUG 2007-08-30 05:18:56,752 {ThreadedMessenger for jxta://uuid-88ACED5024B848F3B5BECC426A5BE4997A9F7D7482B3422A9CE39D622B54C51403} TcpConnection - Sent net.jxta.endpoint.Message@21684929(4){404} successfully via 195.5.36.242:3508
INFO 2007-08-30 05:18:56,822 {BlockingMessenger self destruct timer} TcpConnection - Failure close (open 60007ms) of socket to : tcp://0.0.0.0:0 / 195.5.36.242:3506
DEBUG 2007-08-30 05:18:56,822 {BlockingMessenger self destruct timer} TcpConnection - stack trace
java.lang.Throwable: stack trace
at net.jxta.impl.endpoint.tcp.TcpConnection.close(TcpConnection.java:696)
at net.jxta.impl.endpoint.tcp.TcpMessenger.closeImpl(TcpMessenger.java:229)
at net.jxta.impl.endpoint.BlockingMessenger$BlockingMessengerState.closeOutputAction(BlockingMessenger.java:238)
at net.jxta.endpoint.MessengerState$6.doIt(MessengerState.java:99)
at net.jxta.endpoint.MessengerState.closeEvent(MessengerState.java:235)
at net.jxta.impl.endpoint.BlockingMessenger.close(BlockingMessenger.java:549)
at net.jxta.impl.endpoint.BlockingMessenger$1.run(BlockingMessenger.java:438)
at java.util.TimerThread.mainLoop(Unknown Source)
at java.util.TimerThread.run(Unknown Source)

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
asghar
Offline
Joined: 2005-07-26

Hello,

RendezVousService is one of 6 JXTA standard services.
All JXTA standard services are using pipe (a unidirectional, unreliable message delivery mechanism) to do the necessary communication with each other. Here handling incoming messages can be done based on poling-model or controlled by associated listeners.

I’m wondering that Rdv and its clients can have a time out - featured communication link!
How it is possible?

1. - Can a user configure the JXSE so, that JXSE uses TCP or BiDiPipe (instead UDP) to deliver its 6 standard services to myAPP?

2. - Why your Rdv and clients must use TCP to communicate?

Asghar

PS:

After a more precise look at log - report, it seems, that the caller of close() uses different available ports for different actions BUT within the same “communication-session” as following:

195.5.36.242:[b]1540[/b] vs. 195.5.36.242:[b]4981[/b]

[b]Or[/b]

195.5.36.242:[b]3508[/b] vs. 195.5.36.242:[b]3506[/b]

Is it (also, maybe) the cause for failed close-operation, reported often in other forum’s threads or at mailing list?

What happens, if you change the source code of [b]net.jxta.impl.endpoint.tcp.TcpConnection.close[/b] (TcpConnection.java:[b]696[/b]) so that assigned available IO-port is used for all actions (sending message to Rdv and close the socket, and also other operations, if any…)?

sergeya
Offline
Joined: 2007-08-17

Hello Asghar
1. I have some edge peers, all of them can't reach each other dirrecly as they are in different networks behind firewalls. And I have one public rdv peer. For beeing able to send message from one peer to other peer I should
- at first connect to RDV
- and then create Socket conncetion between peers.
if a peer is disconnected from RDV I'll not have an ability to create socket connection to it.

2. I've used TCP protocol as it works more stable and quickly. maybe I'm worng with that. can you advise which protocol is better?
3 I'll try to experiment with source code