Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cf-dev] Plans regarding CoAP over TCP? 
Hi Simon,

it's great to hear from you again :-) We already worried that you lost
interest in Californium altogether now that Zebra has moved to mbed ...

We are currently heavily struggling with supporting horizontal scale-
out and fail-over of observations with CoAP/UDP. This seems to be very
hard to do in NATed environments so I guess having CoAP/TCP would help
a lot in such scenarios.

I have taken a look at your TCP branch of Californium. I was a little
surprised to see that you implemented TCP at the Connector level. Given
that the encoding of the CoAP messages on the wire is different for UDP
and TCP, I was expecting to see a separate Endpoint implementation for
TCP because 
a) the Connector API uses raw byte arrays containing the
(already/still) encoded CoAP messages sent to/received from the network
in contrast to the Endpoint's Request/Response based API and
b) some of the layers in CoAPEndpoint are not necessary for TCP

So I thought that it is probably not worth the effort to add code for
distinguishing UDP and TCP to CoapEndpoint but instead create a clean &
lean CoapTcpEndpoint instead.

Any thoughts?

-- 
Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com

Registered office: Berlin, Register court: Amtsgericht Charlottenburg,
HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn


On Do, 2016-06-09 at 18:58 +0000, Simon Lemay wrote:
> I had started to reimplement TCP under my GitHub account (Areontar),
> I have a branch that should have the simplistic (just a basic TCP
> connector with CoAP/UDP sematic) version working, but there still a
> lot to be done.  I am still locked in on another project for at least
> 1 week and half, but I have been poking at it when I have time.  I
> use Netty for the connector at the moment and still use the same
> interface.  I should get back on it in 2 weeks or so as we are
> progressing on the draft
> 
> We had a lot of discussion in the pass around what needs to be done
> to make it work.  As Kai mentioned, I think the consensus was to have
> this done in CF2.0 since it would most likely break backward
> compatibility. 
> 
> I would be more than happy to reboot this in about 2 weeks, we can
> get on a hangout with whoever is interested and plan out what we
> need.  What do you guys think?  might be a good time if we can get
> hands on deck and might help resolve some issue on the draft
> 
> cheers,
> Simon
> 
> 
> On Wed, Jun 8, 2016 at 9:17 AM Hudalla Kai (INST/ESY1) <Kai.Hudalla@b
> osch-si.com> wrote:
> > From my point of view it doesn't really make sense to make the
> > CoAPEndpoint distinguish between different transports but instead I
> > think we should create a separate Endpoint implementation, e.g.
> > CoapTcpEndpoint, that then simply does what needs to be done when
> > using
> > TCP (which is a lot less as for running CoAP over UDP as you
> > already
> > figured out).
> > 
> > AFAIK the most important thing will be to get the Endpoint
> > interface
> > right so that it can support exchanging CoAP messages over
> > arbitrary
> > transports. This might include adding the possibility to add
> > callbacks
> > for getting notified when a connection is established or terminated
> > etc).
> > 
> > I am currently more concerned with the Endpoint API and how to make
> > it
> > better support message exchanges in a more "generic" way so that it
> > can
> > work with generic handlers for incoming responses instead of
> > requiring
> > individual handlers for every single request being sent. This will
> > be
> > important for supporting fail-over of observations between nodes.
> > For
> > this scenario, CoAPClient is not really relevant because it will
> > always
> > run in the same process as the Endpoint it uses to interact with
> > the
> > CoAP server, i.e. when the node it runs on crashes there is no need
> > to
> > fail over anything.
> >   
> > --
> > Mit freundlichen Grüßen / Best regards
> > 
> > Kai Hudalla
> > Chief Software Architect
> > 
> > Bosch Software Innovations GmbH
> > Schöneberger Ufer 89-91
> > 10785 Berlin
> > GERMANY
> > www.bosch-si.com
> > 
> > Registered office: Berlin, Register court: Amtsgericht
> > Charlottenburg,
> > HRB 148411 B;
> > Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
> > 
> > 
> > On Mi, 2016-06-08 at 00:12 +0000, Joe Magerramov wrote:
> > > Looking at the spec[1], I'm trying to understand changes to
> > > Californium. On the surface looks like we'll need:
> > >
> > > * A new TCP/TLS connector (it'll need to do non-blocking IO in
> > > receive thread)
> > > * Chagnes to CoAPEndpiont, that when using TCP connector will:
> > > *** Use new data serializer
> > > *** Instruct matcher to skip using MID hashmap puts/gets
> > > *** Skip reliability layer
> > > *** Have a callback from the Connector to cancel all open
> > exchanges
> > > when a TCP connection is dropped
> > >
> > > There's also a question of what to do with Type (CON vs NON) on
> > the
> > > CoapClient APIs. Trivial option just keep them as is, and ignore
> > when
> > > using TCP connector. Less trivial option is to change APIs
> > (how?).
> > >
> > > I'm sure there's something else I'm missing. Thoughts?
> > >
> > > [1] https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls
> > /?in
> > > clude_text=1
> > >
> > >
> > > On Mon, Jun 6, 2016 at 11:57 PM Kai <sophokles.kh@xxxxxxxxx>
> > wrote:
> > > > Not that I am aware of... As Matthias mentioned, Simon Lemay
> > had
> > > > plans for this but it seems priorities have been changed. Maybe
> > you
> > > > want to spark the discussion and get involved? There is
> > definitely
> > > > some interest in it (at least from Bosch), but we are currently
> > > > more focused on adding support for horizontal scalability to
> > > > Californium. TCP support would be something for Cf 2.0, I guess
> > > > since it would probably require some changes to public APIs...
> > > > Kai
> > > >
> > > > Joe Magerramov <joe.magerramov@xxxxxxxxx> schrieb am Di., 7.
> > Juni
> > > > 2016, 04:23:
> > > > > Did not see any e-mail threads on TCP/TLS support since
> > April.
> > > > > Did anybody ever start working on this?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Joe
> > > > >
> > > > > On Fri, Apr 22, 2016 at 3:28 AM Kovatsch Matthias <kovatsch@i
> > nf.e
> > > > > thz.ch> wrote:
> > > > > > Simon (Lemay) had to push this work over to his free time.
> > > > > > Myself not having much time lately does not help either :/
> > > > > > Still, we will need something running for the IETF, so I
> > have
> > > > > > not lost all hope yet :)
> > > > > >  
> > > > > > Ciao
> > > > > > Matthias
> > > > > >  
> > > > > >  
> > > > > > From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@ecl
> > ipse
> > > > > > .org] On Behalf Of Benjamin Cabé
> > > > > > Sent: Montag, 4. April 2016 15:54
> > > > > > To: Californium (Cf) developer discussions <cf-dev@eclipse.
> > org>
> > > > > > Subject: Re: [cf-dev] Plans regarding CoAP over TCP?
> > > > > >  
> > > > > > Ping? :-)
> > > > > > I'm just curious whether it's in the roadmap to provide a
> > TCP
> > > > > > binding in Californium?
> > > > > >  
> > > > > > Thanks!
> > > > > > Benjamin –
> > > > > >  
> > > > > >  
> > > > > > De : Benjamin Cabé <benjamin@xxxxxxxxxxx>
> > > > > > Date : jeudi 4 février 2016 14:37
> > > > > > À : "Californium (Cf) developer discussions" <cf-dev@eclips
> > e.or
> > > > > > g>
> > > > > > Objet : Plans regarding CoAP over TCP?
> > > > > >  
> > > > > > Hi, Californium gang!
> > > > > >  
> > > > > > It looks like the Internet-Draft about CoAP over TCP/TLS
> > [1] is
> > > > > > making good progress, and I was wondering about your
> > views/plan
> > > > > > on making this available in Californium? 
> > > > > > I believe the Zatar guys have worked on a fork of
> > Californium
> > > > > > [2] that does just that since IIRC they are experimenting
> > with
> > > > > > LWM2M over CoAP-TCP.
> > > > > >  
> > > > > > FWIW I get asked very often about CoAP over TCP, as many
> > people
> > > > > > do see lots of value in CoAP itself, but would really like
> > to
> > > > > > see it be more IT/cloud friendly.
> > > > > >  
> > > > > > Looking forward to getting your feedback,
> > > > > > Thanks!
> > > > > > Benjamin –
> > > > > >  
> > > > > > [1] https://datatracker.ietf.org/doc/draft-ietf-core-coap-t
> > cp-t
> > > > > > ls/
> > > > > > [2] https://github.com/zatar-iot/californium/tree/tcp_tls_i
> > mpl
> > > > > >  
> > > > > > Benjamin Cabé – IoT Evangelist
> > > > > >
> > > > > >
> > > > > >
> > > > > > Eclipse Foundation
> > > > > > +33 (0) 619196101
> > > > > > @kartben
> > > > > > _______________________________________________
> > > > > > cf-dev mailing list
> > > > > > cf-dev@xxxxxxxxxxx
> > > > > > To change your delivery options, retrieve your password, or
> > > > > > unsubscribe from this list, visit
> > > > > > https://dev.eclipse.org/mailman/listinfo/cf-dev
> > > > > _______________________________________________
> > > > > cf-dev mailing list
> > > > > cf-dev@xxxxxxxxxxx
> > > > > To change your delivery options, retrieve your password, or
> > > > > unsubscribe from this list, visit
> > > > > https://dev.eclipse.org/mailman/listinfo/cf-dev
> > > > _______________________________________________
> > > > cf-dev mailing list
> > > > cf-dev@xxxxxxxxxxx
> > > > To change your delivery options, retrieve your password, or
> > > > unsubscribe from this list, visit
> > > > https://dev.eclipse.org/mailman/listinfo/cf-dev
> > > _______________________________________________
> > > cf-dev mailing list
> > > cf-dev@xxxxxxxxxxx
> > > To change your delivery options, retrieve your password, or
> > > unsubscribe from this list, visit
> > > https://dev.eclipse.org/mailman/listinfo/cf-dev
> > _______________________________________________
> > cf-dev mailing list
> > cf-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or
> > unsubscribe from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/cf-dev
> _______________________________________________
> cf-dev mailing list
> cf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cf-dev

Back to the top