reef-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Byung-Gon Chun <bgc...@gmail.com>
Subject Re: TransportEvent, RemoteEvent, and Mapping Identifiers to Endpoints in Java
Date Wed, 22 Jun 2016 15:42:11 GMT
Hi Andrew,

Yes, the Java side uses connection caching not to open multiple
connections between two processes for scalability. This's one
implementation. One can extend it to manage k connections between two
processes.

A name client registers an end point id and a network address to a name server.
NetworkService can retrieve this information to resolve an id to a
network address.
Then, the underlying transport uses this network address to create a
connection. Note that this is a unidirectional. To exchange messages
between two processes, we create two connections (e.g., A->B, B->A).

-Gon


On 6/21/16, Andrew Chung <afchung90@gmail.com> wrote:
> Hi all,
>
> I'm having a bit of trouble understanding REEF Networking,
> particularly on the Java side.
>
> In both Java and C#, RemoteEvent has a source and a sink but neither
> are used upon calling the constructor - instead both fields are set
> when receiving a TransportEvent, using the Link's LocalAddress and
> RemoteAddress properties.
>
> I know that in C#, when a process A initiates a connection with
> NetworkService, we use a new TCPClient and get a new TCP Stream - this
> means that we open a new endpoint (host:port) for the client upon
> creating a new connection. On the server side of process B, after it
> accepts the request from process A, it creates a new Link object with
> a remote endpoint of the host:port for the client on process A.
> However, the endpoint is different from what process A registers with
> the NameClient. Process A registers the endpoint of its own Server,
> but not the newly opened endpoint used to initiate the connection.
> This causes a problem in that the server of process B cannot know that
> the connection was initiated by process A.
>
> Is this scenario of concern on the Java side? I notice that Java
> performs some sort of connection caching at the lower level - e.g. if
> process A already has a client connected to process B and process B
> wants to connect to process A, it does not seem to open a new endpoint
> but directly uses the existing connection.
>
> Can the server in Java identify which process initiated the connection
> using the NameClient? How do the LocalAddress and RemoteAddress
> properties get filled in? Do they correspond to what is registered
> using the NameClient?
>
> Thanks,
> Andrew
>


-- 
Byung-Gon Chun

Mime
View raw message