river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: roadmap
Date Tue, 02 Feb 2010 21:34:30 GMT
Peter Firmstone wrote:
> Sim IJskes - QCG wrote:
>>
>> BTW pluggable marshallers, this could provide us for a place to put an 
>> auto-exporter in. We could with annotations/interfaces signal verify 
>> the intent. (i'm sure i'm not the first one thinking that).
> This is going to be interesting, especially considering NAT's will 
> change ports randomly, the Marshalled Object / Proxy instance won't know 
> their way home, they'll probably need to find their location on an event 
> que or something like that.

To break through unrouted paths due to NAT, it would probably be better to rely 
on connectivity reversal in the endpoint implementations. A call through the 
endpoints in one direction, could cause traffic in the opposing direction to 
request a remote inbound connection, and then use that connection.

The problem is that when a service exports a marshalled proxy instance into a 
lookup server, the unmarshalling of (an instance of) the proxy is invisible to 
the service.

I haven't been able to read all of the details of what you all have discussed 
because some of the words are not sinking in.

However, the bigger issue is the NAT traversal issue.  If there are not fixed 
port numbers and port forwarding through the NATing device, I'm not sure there 
is a solution that doesn't involve a proxying host (which you all did discuss).

That becomes a bottle neck and a resource that is difficult to manage.

Maybe we need an endpoint implementation which knows how to use uPnP for port 
forwarding configuration on consumer routers?  More and more software is using 
uPnP for port forwarding.

Microsofts Home Server knows how to do this, and there are others that I've seen 
doing this to provide appropriate port forwarding changes.

Gregg Wonderly

Mime
View raw message