TransportEvent, RemoteEvent, and Mapping Identifiers to Endpoints in Java

[Andrew Chung <af...@gmail.com>]

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

Re: TransportEvent, RemoteEvent, and Mapping Identifiers to Endpoints in Java

[Andrew Chung <af...@gmail.com>]

Thanks for the answers!

@Gon Given that we create two connections for message exchange from
A->B and B->A, can the server know who (in terms of the identifier
registered to the Name Server) is contacting it based on
`Link.getRemoteAddress()`? If I understood the code correctly,
`Link.getRemoteAddress()` returns the endpoint of the client created
to initiate the connection, but not the endpoint that the
NetworkService's server registered with the Name Server.

I believe this was the issue that `RemoteEvent.getRemoteAddress()` is
supposed to address, since in `ProxyEventHandler`, we pass in
`myId.getSocketAddress()`, which is the address of the
*NetworkService's server* for the local address parameter on line 75,
though we don't properly serialize/deserialize the address as we trace
through the code to the other end. Instead, we just fill the fields in
with `Link.getRemoteAddress()` on the receiving end. Is this the right
behavior? Does `Link.getRemoteAddress()` return the same address as if
you pass in `myId.getSocketAddress()` in `ProxyEventHandler`?

I'm concerned because registering `Handlers` with `HandlerContainer`
is contingent on knowing the `RemoteIdentifier` beforehand, and if the
client sets up a new connection contacting the Server without using
the endpoint that the Server registers with the `NameClient`, we may
not have a way of knowing the `RemoteIdentifier` in order to register
with `HandlerContainer`. This is a *severe* problem of the C#
equivalent `ObserverContainer`, but I'm not sure if this problem
exists in Java or not.

Sorry for the long list of questions and I hope they make sense, but I
would really like to 1) see if `RemoteEvent` is behaving correctly
w.r.t. filling in the local/remote address fields and 2) understand
this to get REEF-1459[0] and REEF-1453[1] to work. If it is not
behaving as intended, we may need a new protocol such as sending
`myId.getSocketAddress()` properly on the first message for each given
client to a NetworkService. (Or perhaps there is a better way around
this that I'm not seeing :) )

Thanks,
Andrew

--
[0]: https://issues.apache.org/jira/browse/REEF-1459
[1]: https://issues.apache.org/jira/browse/REEF-1453

On Wed, Jun 22, 2016 at 9:01 AM, Markus Weimer <ma...@weimo.de> wrote:
> On 2016-06-20 16:38, Andrew Chung wrote:
>>
>> 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.
>
>
> That is by design. In very large systems, the number of network
> connections a machine needs to manage becomes a bottleneck in its own
> right. Hence, we made an effort to achieve a situation where there is at
> most 1 connection between any pair of Evaluators in a REEF job. We should
> strive for the same behavior in .NET.
>
> Markus

Re: TransportEvent, RemoteEvent, and Mapping Identifiers to Endpoints in Java

[Markus Weimer <ma...@weimo.de>]

On 2016-06-20 16:38, Andrew Chung wrote:
> 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.

That is by design. In very large systems, the number of network
connections a machine needs to manage becomes a bottleneck in its own
right. Hence, we made an effort to achieve a situation where there is at
most 1 connection between any pair of Evaluators in a REEF job. We 
should strive for the same behavior in .NET.

Markus

Re: TransportEvent, RemoteEvent, and Mapping Identifiers to Endpoints in Java

[Byung-Gon Chun <bg...@gmail.com>]

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 <af...@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

Re: TransportEvent, RemoteEvent, and Mapping Identifiers to Endpoints in Java

[Dhruv Mahajan <dh...@gmail.com>]

Shravan, Markus, Gon you guys have better idea on Java side. Can you help
Andrew on this?

Dhruv

On Mon, Jun 20, 2016 at 4:38 PM, Andrew Chung <af...@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
>