reef-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Chung (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (REEF-1459) RemoteEvent should encode the source and dest on Serialization
Date Fri, 17 Jun 2016 16:49:05 GMT

    [ https://issues.apache.org/jira/browse/REEF-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15336440#comment-15336440
] 

Andrew Chung edited comment on REEF-1459 at 6/17/16 4:48 PM:
-------------------------------------------------------------

It is used to identify the server's endpoint from the server on the other side of the network.
When we use a {{NetworkService}} to open a new connection, it sets up a new {{TCPClient}}
and opens a new port different from the endpoint used in its own server. However, its server's
endpoint is the one registered with the name client, so when the server on the other end of
the network receives an incoming request, it has no way of mapping the request to the name
client entry as registered by the server on the side initiating the connection. I believe
that was the original point of the source and sink in {{RemoteEvent}}, though currently it
doesn't do anything and {{null}} is passed in.

Alternatively, we can implement this as something at the GroupCommunication layer instead,
so we serialize the server's identifier when initiating a new message in {{GeneralGroupCommmunicationmessage}}.
I am fine with either way, but I figured that if {{RemoteEvent}} already has the {{source}}
and {{sink}} fields set up, we should utilize it instead of allowing the current ambiguous
behavior.


was (Author: afchung90):
It is used to identify the server's endpoint from the client side. When we use a {{NetworkService}}
to open a new connection, it sets up a new {{TCPClient}} and opens a new port different from
the endpoint used in the server. The server's endpoint is the one registered with the name
client, so when the server on the other end of the network receives a n incoming request,
it has no way of mapping the request to the name client entry as registered by the server
on the side initiating the connection. I believe that was the original point of the source
and sink in {{RemoteEvent}}, though currently it doesn't do anything and {{null}} is passed
in.

Alternatively, we can implement this as something at the GroupCommunication layer instead,
so we serialize the server's identifier when initiating a new message in {{GeneralGroupCommmunicationmessage}}.
I am fine with either way, but I figured that if {{RemoteEvent}} already has the {{source}}
and {{sink}} fields set up, we should utilize it instead of allowing the current ambiguous
behavior.

> RemoteEvent should encode the source and dest on Serialization
> --------------------------------------------------------------
>
>                 Key: REEF-1459
>                 URL: https://issues.apache.org/jira/browse/REEF-1459
>             Project: REEF
>          Issue Type: Task
>          Components: REEF, Wake, Wake.NET
>            Reporter: Andrew Chung
>            Assignee: Andrew Chung
>
> When a new {{RemoteEvent}} is created in the Java side, the source is set as the {{TransportServer}}
's endpoint. However, upon going through serialization, the endpoint is set to {{null}} and
instead we rely on the connection to get the source. The source is used to identify the {{TransportServer}}
ID instead of the actual connection source such that the receiving end can reversely set up
connections to the server, but right now the source is not serialized properly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message