Skip to main content

Can a peer use a Relay for group communication and also be a Rendezvous?

6 replies [Last post]
enygma2002
Offline
Joined: 2008-12-22
Points: 0

Hi guys!

It's been a while since I posted and I see the forum has gone quite silent, but here goes nothing:

This thread is related to an earlier one ( http://forums.java.net/jive/thread.jspa?messageID=339599#339599 ) where it was concluded that, in order to use a relay peer (if your ports are blocked), you have to set a relay seed but that is not enough. You must *also* set to not allow HTTPIncoming and TCPIncoming connections so that the relay peer does not try to contact you (you are unreachable from his point of view) and that you will poll the data from him (done by jxta automagically).

In this scenario, when you disable HTTPIncoming and TCPIncoming, you do so for your whole connection. There is no option to say, do these changes only for the an outside network, but not for an inside one.

A scenario would be the one when a peer becomes RDV or whishes to act as RDV for a group, but the peer is not connectible from the outside so it has to use a relay to communicatie with outside group members. In the same time, it wants to be a RDV because it wants to serve other peers inside his LAN, which are in the same (unreachable from the outside) situation as our peer is.
If our peer just disabled incoming connections, in order to use the relay and talk to outside peers, how will it be able to talk to his inside (LAN) peers that wish to use him as RDV/RELAY? The other peers don't know our peer's relay and they don't care. They only know our peer and we are in charge of connecting them.

Jxta supports this out of the box, as advertised, but in reality, can it really do that? Or every peer *needs* to know the "master" relay seeds and needs to use them? If this is the case(and so it may seem), it's not that nice.

Thank you for your attention and hope to see some nice answers from you guys.

Cheers!

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
adamman71
Offline
Joined: 2007-01-31
Points: 0

This thread is related to an earlier one ( http://forums.java.net/jive/thread.jspa?messageID=339599#339599 ) where it was concluded that, in order to use a relay peer (if your ports are blocked), you have to set a relay seed but that is not enough. You must *also* set to not allow HTTPIncoming and TCPIncoming connections so that the relay peer does not try to contact you (you are unreachable from his point of view) and that you will poll the data from him (done by jxta automagically).

-> I would like to comment the above: it is not a requirement to block incoming traffic in order to be able to use a relay. It is not a requirement.

There is no option to say, do these changes only for the an outside network, but not for an inside one.

-> You can block traffic at the router/NAT level if it is an absolute necessity.

If our peer just disabled incoming connections, in order to use the relay and talk to outside peers, how will it be able to talk to his inside (LAN) peers that wish to use him as RDV/RELAY?

-> Use multicasting

Hope this helps,

J.

enygma2002
Offline
Joined: 2008-12-22
Points: 0

Hi and thanks for the reply!

> This thread is related to an earlier one (
> http://forums.java.net/jive/thread.jspa?messageID=3395
> 99#339599 ) where it was concluded that, in order to
> use a relay peer (if your ports are blocked), you
> have to set a relay seed but that is not enough. You
> must *also* set to not allow HTTPIncoming and
> TCPIncoming connections so that the relay peer does
> not try to contact you (you are unreachable from his
> point of view) and that you will poll the data from
> him (done by jxta automagically).
>
> > I would like to comment the above: it is not a
> requirement to block incoming traffic in order to be
> able to use a relay. It is not a requirement.

I know it is not written anywhere, but from practice and actual implementation tests I haven't been successful in using a relay without turning Incoming connections *off* by using the NetworkConfigurator instance.
If I do not do so (see earlier thread), the relay will try to send messages back to the peers and since they are firewalled, it will fail with connection timeout/refused exceptions. Also, the peer will not poll for messages, thus the messages will never be received by my peer.

I suspect that the relay reads the peer's route(?) advertisement and sees that incomming connections are accepted and, thus, will try to send the messages back to the peer directly.
But, if a peer disables incomming connections (by using jxta methods - NetworkConfigurator, not network methods - routers/NATs) it will automatically poll for messages (as jxta states in the docs) and the relay peer will see that from the peer's route(?) advertisement and will not try to send the messages back to the peer. Instead, it will wait for the peer to poll the messages it has to receive.

This actually makes sense because of what I can see from practice. I would also appreciate some other points of views.

I am currently successfully using relay peers, but only by turning incomming connections *OFF* on the peers that need to use the relays. It would be nicer if jxta automagically detected these scenarios and would not require user configuration. Not all users know their network's status.

>
> There is no option to say, do these changes only for
> the an outside network, but not for an inside one.
>
> -> You can block traffic at the router/NAT level if
> it is an absolute necessity.

Actually I was not trying to block access, instead to allow it. I am initially blocking incomming connections for the outside network that I am joining but want to accept incomming connections from LAN peers that want to use me as RDV/Relay seed.

>
> If our peer just disabled incoming connections, in
> order to use the relay and talk to outside peers, how
> will it be able to talk to his inside (LAN) peers
> that wish to use him as RDV/RELAY?
>
> -> Use multicasting

Multicast would probably help for discovering my peer by other peers, but when it comes down to connecting to my peer, they will be refused by jxta. (I have incomming connections set to false)

>
> Hope this helps,
>
> J.

Thanks again.
Hope to hear more about this!

ivarulz
Offline
Joined: 2007-08-17
Points: 0

My configurations:

if ( isModerator ) {
configurator.setTcpEnabled ( true );
configurator.setTcpIncoming ( true );
configurator.setTcpOutgoing ( true );

configurator.setHttpEnabled(true);
configurator.setHttpIncoming(true);
configurator.setHttpOutgoing(true);
configurator.setHttpPort(81);
} else {
configurator.setTcpEnabled ( false );
configurator.setTcpIncoming ( false );
configurator.setTcpOutgoing ( false );

configurator.setHttpEnabled(true);
configurator.setHttpIncoming(true);
configurator.setHttpOutgoing(true);
}

My moderator peer is somewhere on the internet and my peers are working behind NAT/firewall.

Basically I'm shutting down TCP communication.

Iva

enygma2002
Offline
Joined: 2008-12-22
Points: 0

Thanks for your insight iva!

For your configuration, you shouldn't need TCP at all for the moderator, if all your normal peers use only HTTP, right?

Also, you are using HTTP communication to contact the moderator(Relay peer I presume).

I will try that too, but for now I was successfully using only TCP communication to contact and use a Relay but it works *only* if I disabled TCP incoming connections.

If you say it is working for HTTP with incoming ON, then it should work for TCP as well, but it does not.

Can anybody explain why?

In your case, probably HTTP incoming is never actually used anyway (if your peer is behind a firewall it can not receive incoming connections) but, if what you say is correct, it seems that the relay is smart enough to detect that it can not send your messages back to you directly so it waits for you to poll for them.

In TCP, however, the relay is not that smart(why!?). It will try to send to you your messages continuously. That would not be a problem if you actually would poll for the messages at one time, but that does not happen either!

Can anybody clear this out?

Thanks!

ivarulz
Offline
Joined: 2007-08-17
Points: 0

I think you need to have HTTP incoming on because in real world not all peers are behind NAT, so you need to allow them to use their natural connectivity.
I never tested outside this configuration: internet available moderator peer + firewalled/nat peers.

I think i'll use the TCP connections for inter-moderator communication, if I deploy more moderators in the same LAN. But that is for the future.

Iva

enygma2002
Offline
Joined: 2008-12-22
Points: 0

> I think you need to have HTTP incoming on because in
> real world not all peers are behind NAT, so you need
> to allow them to use their natural connectivity.
> I never tested outside this configuration: internet
> available moderator peer + firewalled/nat peers.

I agree with you Iva on this, but why doesn't it work the same for TCP on firewalled/nat-ed peers? (incoming connections set to on)
Why can't a TCP Relay "see" that, although set to incoming ON, the receiver peer can't really receive the message and why can't it wait for the peer to poll the messages himself like it does for HTTP (assuming that it works for you)?

>
> I think i'll use the TCP connections for
> inter-moderator communication, if I deploy more
> moderators in the same LAN. But that is for the
> future.
>
> Iva

Another thing I don`t really understand is why would you actually use HTTP instead of TCP anyway?

HTTP is, AFAIK, much more verbose (text) an thus has a much greater load on the network.

TCP, if used to transfer binary data, would have a much lesser impact on the network and would be preferred.

As I argued on another thread ( http://forums.java.net/jive/thread.jspa?threadID=60880&tstart=0 ), I don`t understand why it is differentiate between HTTP and TCP at a network transport protocol level when they are not that independent one from each other. (HTTP is on top of TCP)

If you set your TCP port to 80, you should get the same result from a network's point of view as you would using "HTTP communication" and you should have a much lesser traffic. You would only have problems when you have some protocol-level filtering on the firewalls, but this is expensive and is very rarely encountered.

So my argument still stands... why use HTTP instead of TCP when it obviously works, but why doesn't TCP work both ways (incoming and outgoing), like Iva says it does for HTTP. Is it an incomplete implementation done for TCP?

It would be really nice if we could get to get to the bottom of this.

Thanks.