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
