Hi,
thank you for the reply and the hints. I think that i will follow the discussion regarding to such PR, and in the meanwhile i will use the described “patch” for our internal testing purpouses and think about a feasible solutions.
best regards!
Simone Bolettieri
Simone Bolettieri
Dear Simone,
though I’m not using californium in an environment, where multicast would makes sense, I didn’t work on that issues. There are PRs (e.g. https://github.com/eclipse/californium/pull/394)
about that, but, as you found out, it’s not possible to test them without further changes.
If you want to work on it, and may be other wants also to contribute, I would go for a “multicast” branch to evolve that feature. Depending on the detection of “responses” for
a multicast request, we either could change to used lookup keys, or, create a special “CoapMulticastStack” with a special Connector to separate the multicast messages.
But unfortunately, PR
https://github.com/eclipse/californium/pull/401
and issue,
https://github.com/eclipse/californium/issues/398
would change a lot of the 2.0.x stuff.
So I’m not sure, if this is the right point in time to start the fixing of the “multicast” feature.
Mit freundlichen Grüßen / Best regards
Achim Kraus
(INST/ECS4)
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen |
GERMANY |
www.bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Simone Bolettieri
Sent: Montag, 11. September 2017 13:16
To: cf-dev@xxxxxxxxxxx
Subject: [cf-dev] Multicast support for Californium
Dear community,
I recently started working on a project which requires a Californium CoAP server able to accept CoAP Multicast request. Some other guys attempted to merely bind the CoAPServer to a Multicast address without success. I decided to investigate. After some reverse
engineering, it turned out that the problem is relative to the fact that the class CoAPEndpoint is based on Unicast socket (DatagramSocket Java type). In fact, the correct way to be able to receive Multicast request (more in general packets) in Java it’s to
use a MulticastSocket (bound to a port if necessary) . Once a Multicastsocket is created it’s possible to register to a Multicast Group (through a Multicast address).
Starting from those considerations, as a proof of concept i tried to introduce server side Multicast support. To do so I created a class called UDPMulticastConnector (for now it’s a modifed copy of UDPConnector, but I think that could be implemented by extending
UDPConnecotr). In such class the socket used is a MulticastSocket. Furthermore it supports methods to subscribe/unsubscribe to groups. Another modification has to be done in the function “createUDPConnector” located in CoAPEndpoint. Such function has to
be aware of what kind of socket the server needs, so it can decide if a unicast or Multicast UDPConnector must be created.
Those set of modifications are sufficient for being able to receive Multicast requests. A client wishing to send a Multicast request simply specifies a multicast address as destination endpoint. The server will receive the request process it and reply back
to the client in Unicast (even if the socket is multicast, it doesn’t matter, the only problem could be related to TTL limits, but I have to investigate) .
However now it comes a bigger issue. To recognize an incoming reply, the client uses a matching process which involves the couple [reply source address, Token ID]. To be more precise when the client sends the request it will register the
origin exchange with the key: [destination address, TokenID]; when it receives a reply it searches the keyTable for a match using as a key: [reply source address, Token ID] , to locate the origin exchange. The problems regards the fact that while the request
has the group multicast address as the destination address, the response comes in Unicast with a server unicast address as a source address. This situation causes a mismatch.
Again as a proof of concept, I implemented a message interceptor on client side which swaps the source address of the incoming reply (from a multicast request) with the multicast group address used in the request. The result shows that the matcher succeeded
in finding the proper exchange and leaving the process consume the response.
So what is missing now is a way to turn such “magic swap” into something more feasible. Any opinion, suggestion and feedback would be greatly appreciated.
S.B.
