[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [leshan-dev] Use registration Endpoint URI in Client object
|
Hi Kai,
great!
Currently I try to make the notifies also work for tcp.
I have already made progress in the demo client and demo server using tcp.
Still open are:
- notifies (coupled via ObservationStore and NotificationListener)
- parameters for the demos to specify the UDP/TCP usage
- "credentials" (TLS connection initially works, but there is no endpoint credentials check and only x509)
Mit freundlichen Grüßen / Best regards
Achim Kraus
Bosch Software Innovations GmbH
Communications (INST/ESY1)
Stuttgarter Straße 130
71332 Waiblingen
GERMANY
www.bosch-si.de
www.blog.bosch-si.com
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn
-----Ursprüngliche Nachricht-----
Von: leshan-dev-bounces@xxxxxxxxxxx [mailto:leshan-dev-bounces@xxxxxxxxxxx] Im Auftrag von Hudalla Kai (INST/ESY1)
Gesendet: Freitag, 4. November 2016 15:11
An: leshan-dev@xxxxxxxxxxx
Betreff: Re: [leshan-dev] Use registration Endpoint URI in Client object
On Do, 2016-11-03 at 09:22 +0000, Kraus Achim (INST/ESY1) wrote:
> Hi List,
>
> I tested a little with the "improve_builder" branch.
> I think PR #194 is required to make notifications over coaps working again.
>
I have merged that PR to the "improve_builder" branch and I also have rebased the branch onto master so that we are "up to date".
> >
> > In the course of figuring out what would need to be changed I
> > stumbled across the fact that we keep references to the
> > "nonSecureEndpoint" and the "secureEndpoint" all over the place. My
> > understanding was that we do this mostly in order to be able to
> > determine, whether a request uses a secured endpoint or not. I think
> > that this is not very elegant and it also limits us to use one
> > non-secure and one secure endpoint. But what if we want to use a
> > secure endpoint for coap and one for coap+tcp?
> I also stumbled into that when trying to use the TCP connectors.
> There are still some functions left, where the tupel of plain and
> secure endpoint is used (CaliforniumObservationRegistry,
> CaliforniumLwM2mBootstrapRequestSender),
> So I would like to change them to "Set<Endpoint>" as well.
>
> Are there any issues, not doing so?
> I would prepare the changes then into an additional branch based on
> "improve_builder", right?
>
IMHO we should definitely replace the explicit "nonSecure" and "secure" endpoint references with the a Set<Endpoint> reference. If you want to do that create another PR against the "improve_builder" branch (don't forget to first fetch the branch since I have rebased it).
> Mit freundlichen Grüßen / Best regards
>
> Achim Kraus
>
> Bosch Software Innovations GmbH
> Communications (INST/ESY1)
> Stuttgarter Straße 130
> 71332 Waiblingen
> GERMANY
> www.bosch-si.de
> www.blog.bosch-si.com
>
> Registered office: Berlin, Register court: Amtsgericht Charlottenburg,
> HRB
> 148411 B
> Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: leshan-dev-bounces@xxxxxxxxxxx
> [mailto:leshan-dev-bounces@xxxxxxxxxxx] Im Auftrag von Hudalla Kai
> (INST/ESY1)
> Gesendet: Montag, 10. Oktober 2016 16:17
> An: leshan-dev@xxxxxxxxxxx
> Betreff: [leshan-dev] Use registration Endpoint URI in Client object
>
> Hi,
>
> I have been playing around with the LeshanDemoServer during the last
> weeks and had some problems figuring out how to configure it with
> Californium Endpoints managed by my client code, i.e. not implicitly created by LeshanServerBuilder.
>
> In the course of figuring out what would need to be changed I stumbled
> across the fact that we keep references to the "nonSecureEndpoint" and
> the "secureEndpoint"
> all over the place. My understanding was that we do this mostly in
> order to be able to determine, whether a request uses a secured
> endpoint or not. I think that this is not very elegant and it also
> limits us to use one non-secure and one secure endpoint. But what if
> we want to use a secure endpoint for coap and one for coap+tcp?
>
> On Californium's 2.0.x branch I have therefore added a getUri() method
> to the Endpoint interface which can be used to determine both the
> protocol the Endpoint supports as well as the socket address it
> listens on. Based on this I have made a small change to leshan's
> Client class to now keep the registration Endpoint's URI instead of
> merely the socket address. This, however, also required some small changes in some other dependent classes as well.
>
> I have pushed the "improve_builder" branch to the leshan repo
> containing these changes as well as a change to LeshanServerBuilder
> allowing client code to provide a set of arbitrary Endpoints to be used when building the LeshanServer.
>
> Do these changes pose a problem to you guys? In particular the change
> to Client might have an impact on a custom (persistent) implementation
> of ClientRegistry, I guess ...
>
> I would otherwise like to create an M3 milestone of Californium 2.0.x
> in order to be able to create a PR ...
>
> --
> 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
> _______________________________________________
> leshan-dev mailing list
> leshan-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/leshan-dev
> _______________________________________________
> leshan-dev mailing list
> leshan-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/leshan-dev
_______________________________________________
leshan-dev mailing list
leshan-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/leshan-dev
