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?
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@xxxxxxxxxxxx> 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@inf.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@eclipse
> > > > .org] On Behalf Of Benjamin Cabé
> > > > Sent: Montag, 4. April 2016 15:54
> > > > To: Californium (Cf) developer discussions <cf-dev@xxxxxxxxxxx>
> > > > 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@xxxxxxxxxx
> > > > 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-tcp-t
> > > > ls/
> > > > [2] https://github.com/zatar-iot/californium/tree/tcp_tls_impl
> > > >  
> > > > 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

Back to the top