You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Dan Smith <ds...@pivotal.io> on 2020/03/31 17:17:29 UTC

[DISCUSS] Replace UDP messaging for membership with TCP

Hi all,

We created a RFC for replacing our UDP messaging  in Geode with a TCP based
solution. This will address the issues we have supporting our current udp
encryption solution, along with helping us move away from jgroups, which
currently can't be upgraded.

Please review and comment by 4/7/2020.

https://cwiki.apache.org/confluence/display/GEODE/Replace+UDP+messaging+for+membership+with+TCP

Thanks!
-Dan

Re: [DISCUSS] Replace UDP messaging for membership with TCP

Posted by Dan Smith <ds...@pivotal.io>.
It looks like we have consensus to move forward with this proposal. Thanks
all for your comments! I've moved it into "In Development"

Thanks,
-Dan

On Fri, Apr 3, 2020 at 4:47 PM Aaron Lindsey <aa...@apache.org>
wrote:

> This proposal sounds good to me. +1 to using standard security
> implementation based on TLS
>
> > On Apr 1, 2020, at 3:20 PM, Dan Smith <ds...@pivotal.io> wrote:
> >
> >> When we move from a reliable UDP implementation to one based on TCP, we
> >> need to think about how to provide reliability on top of TCP.  If you
> dig
> >> into TCP, you’ll find that it tries really hard (sometimes up to 15
> >> minutes!!) but doesn’t guarantee message delivery.  Does this matter in
> >> practice?  Yes it does--I’ve worked on geode issues where a faulty
> network
> >> cable eventually caused a cluster hang because of a dropped TCP packet.
> >>
> >
> > +1. Yes, we are proposing that the new messenger needs to be able to
> > recreate the TCP connection and resend any unacked messages.
> >
> > -Dan
>
>

Re: [DISCUSS] Replace UDP messaging for membership with TCP

Posted by Aaron Lindsey <aa...@apache.org>.
This proposal sounds good to me. +1 to using standard security implementation based on TLS

> On Apr 1, 2020, at 3:20 PM, Dan Smith <ds...@pivotal.io> wrote:
> 
>> When we move from a reliable UDP implementation to one based on TCP, we
>> need to think about how to provide reliability on top of TCP.  If you dig
>> into TCP, you’ll find that it tries really hard (sometimes up to 15
>> minutes!!) but doesn’t guarantee message delivery.  Does this matter in
>> practice?  Yes it does--I’ve worked on geode issues where a faulty network
>> cable eventually caused a cluster hang because of a dropped TCP packet.
>> 
> 
> +1. Yes, we are proposing that the new messenger needs to be able to
> recreate the TCP connection and resend any unacked messages.
> 
> -Dan


Re: [DISCUSS] Replace UDP messaging for membership with TCP

Posted by Dan Smith <ds...@pivotal.io>.
> When we move from a reliable UDP implementation to one based on TCP, we
> need to think about how to provide reliability on top of TCP.  If you dig
> into TCP, you’ll find that it tries really hard (sometimes up to 15
> minutes!!) but doesn’t guarantee message delivery.  Does this matter in
> practice?  Yes it does--I’ve worked on geode issues where a faulty network
> cable eventually caused a cluster hang because of a dropped TCP packet.
>

+1. Yes, we are proposing that the new messenger needs to be able to
recreate the TCP connection and resend any unacked messages.

-Dan

Re: [DISCUSS] Replace UDP messaging for membership with TCP

Posted by Anthony Baker <ab...@pivotal.io>.
Echo’ing my comment here:

When we move from a reliable UDP implementation to one based on TCP, we need to think about how to provide reliability on top of TCP.  If you dig into TCP, you’ll find that it tries really hard (sometimes up to 15 minutes!!) but doesn’t guarantee message delivery.  Does this matter in practice?  Yes it does--I’ve worked on geode issues where a faulty network cable eventually caused a cluster hang because of a dropped TCP packet.

One technique for dealing with this is to pair requests and responses.  If a response is not received within a timeout, close the socket and assume any incomplete requests must be resent.


While DTLS looks interesting, it does impose some constraints on packets that could lead to poor performance.  I think overall we’ll be better suited to focus on TCP for secure transport.

Anthony



> On Mar 31, 2020, at 10:17 AM, Dan Smith <ds...@pivotal.io> wrote:
> 
> Hi all,
> 
> We created a RFC for replacing our UDP messaging  in Geode with a TCP based
> solution. This will address the issues we have supporting our current udp
> encryption solution, along with helping us move away from jgroups, which
> currently can't be upgraded.
> 
> Please review and comment by 4/7/2020.
> 
> https://cwiki.apache.org/confluence/display/GEODE/Replace+UDP+messaging+for+membership+with+TCP
> 
> Thanks!
> -Dan


Re: [DISCUSS] Replace UDP messaging for membership with TCP

Posted by Mark Hanson <mh...@pivotal.io>.
Can we document the protocol this time?

Thanks,
Mark

> On Mar 31, 2020, at 10:17 AM, Dan Smith <ds...@pivotal.io> wrote:
> 
> Hi all,
> 
> We created a RFC for replacing our UDP messaging  in Geode with a TCP based
> solution. This will address the issues we have supporting our current udp
> encryption solution, along with helping us move away from jgroups, which
> currently can't be upgraded.
> 
> Please review and comment by 4/7/2020.
> 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FReplace%2BUDP%2Bmessaging%2Bfor%2Bmembership%2Bwith%2BTCP&amp;data=02%7C01%7Chansonm%40vmware.com%7C5419f5b82bd94c98484a08d7d597724e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637212718744094716&amp;sdata=yF7o7Cns%2B1QOGQKKvXhJmVtnZGIiCjsuOskNjIEd8Ag%3D&amp;reserved=0
> 
> Thanks!
> -Dan