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.
