river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Firewall traversal
Date Wed, 20 Jul 2011 12:04:45 GMT
Sim IJskes - QCG wrote:
> On 19-07-11 02:35, Peter Firmstone wrote:
>> 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
>
> I think that we only reach an optimal trust situation when we reduce 
> the jeri endpoint concept to a stream based solution, and transmit 
> this stream in blocks, and run an TLS session over this stream.
>
> In order to create this we could factor out of a current endpoint 
> solution an abstract endpoint with an abstracted stream/block 
> transport. We can then create concrete endpoint solutions where an 
> transport is plugged into the endpoint. This transport could be 
> fetched from a factory based on URL.
>
> Gr. Sim
>
At this early stage, I'd like to keep it simple, I'm not looking at 
dynamic address lookup, thinking about it is an interesting exercise, so 
in the initial implementation, if the connection dies, that's it.

The Endpoint implementations I'm interested in are the SSLEndpoint's.

Do you think the service needs to know it's external NAT address prior 
to Exporting, or discovering it at Export time is good enough?

Only the ServerEndpoint needs to know the address to set into it's 
client Endpoint and I was thinking that could be performed by the 
ServerSocketFactory, when the Endpoint is given the Server's SocketAddress.

Because UDP is connectionless, it makes it easier for UDT to traverse 
NAT's, but it's worth noting that UDT uses connections, congestion 
control and retransmissions at the application level, to a NAT, it's 
just UDP.

Cheers,

Peter.

Mime
View raw message