Mailing-List: contact dev-help@reef.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@reef.apache.org
Date: Thu, 25 May 2017 22:38:04 +0000 (UTC)
From: "Byung-Gon Chun (JIRA)" <jira@apache.org>
To: dev@reef.apache.org
Message-ID: <JIRA.12837297.1434075057000.298005.1495751884532@Atlassian.JIRA>
In-Reply-To: <JIRA.12837297.1434075057000@Atlassian.JIRA>
References: <JIRA.12837297.1434075057000@Atlassian.JIRA> <JIRA.12837297.1434075057087@jira-lw-us.apache.org>
Subject: [jira] [Commented] (REEF-362) Implement a Wake Transport using HTTP
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 25 May 2017 22:38:15 -0000


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

Byung-Gon Chun commented on REEF-362:
-------------------------------------

[~nhne] You can use a component in Netty. Wake's built on Netty. We probably don't want to introduce another library dependency in Wake.


> Implement a Wake Transport using HTTP
> -------------------------------------
>
>                 Key: REEF-362
>                 URL: https://issues.apache.org/jira/browse/REEF-362
>             Project: REEF
>          Issue Type: Improvement
>          Components: Wake, Wake.NET
>            Reporter: Markus Weimer
>              Labels: GSoC, gsoc2017
>
> Wake currently uses TCP connections for its messages. This is fast and efficient, but provides challenges in some network environments. Also, it is considerable work to support authentication and encryption.
> We could provide HTTP(S) as an alternative protocol for Wake. This transport will likely be less efficient than the current path, but gain in security. And for the relatively small messages used by the REEF control flow, the trade-off is likely worth it.


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)