On 19-07-11 02:35, Peter Firmstone wrote:
If you take a look at TcpServerEndpoint.enumerateListenEndpoints where
the TcpEndpoint is created (or fetched) for export, where it is
serialized. You will see there that the endpoint description consists
of host, port and socketFactory.
In the TcpEndpoint this will be used to create the socket. The socket
will be created with the sf.createSocket() call, and after creation
the socket.connect(socketAddress, timeout); will be called.
This socketAddress will always be a InetSocketAddress. Do you see
opportunities to do some translation or lookup in there?
Now that is interesting, because dynamic ip addresses can change, or a
NAS can change the external port, but I'm not sure how suitable Dynamic
DNS is, there are companies on the net like www.dyndns.com who provide
such a service, but this requires setting up an account, or human
My point is, if you want to be compatible with the original TcpEndpoint
i've seen no opportunity to create a TcpServerEndpoint and have it
proxied on a server with a public internet address. A TcpServerEndpoint
needs to know the public hostname in advance, before the
ServerSocketFactory is called. Even dynamic DNS lookup will fail IMHO
because of the caching that the JavaVM does.
You need to contact the ServerEndpoint proxy before the
ServerSocketFactory is called. One could create a factory for creating
ServerEndpoints on a proxy, and have it delegate endpoint creation to
the proxy (maybe not needed). IMHO The work involved in creating a
SocketImpl is expensive, if you have to give up transparancy, better
create a new Endpoint twin.
intervention. Sun's Neuromancer project had a remote reference service
which used distributed hash tables, a proxy could rediscover the
ServerEndpoint after it moved by looking up an Xuid, (similar to a
Uuid). The problem they ran into; the service and proxy needed to be
trust verified again after the connection was reestablished, but
permissions had already been granted. To make matters worse it was the
proxy itself that had to locate the ServerEndpoint.
It all revolves around the identity of the endpoint, and how much
information is contained in it. In case of a TURN based solution the
proxy server hostname should be contained in it.
I would have expected a URL based endpoint description mechanism in
JERI. I'm not sure why not. Planned for V3 maybe?
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
