On Wednesday 01 April 2015 12:28:04 Thiago Macieira wrote: > On Wednesday 01 April 2015 19:57:07 Carsten Bormann wrote: > > I didn't do the code dive yet, so I don't understand why there are two > > sockets (me not understanding doesn't mean it's wrong). If one is for > > unicast and one for multicast, I'd rather reply to the multicast on the > > multicast socket. The unicast socket should then simply ignore packets > > sent to the multicast address, which can be done by binding to a > > specific address (except apparently on Windows) and/or by looking at the > > PKTINFO of any received packet. > > I don't see why two sockets would be needed. Maybe someone can clarify, > though. > > A single socket is enough for sending unicast and multicast, as well as for > receiving unicast and multicast. > > The one reason I'd see for having separate sockets would be if we needed to > send from different ports. You can't send from a different port than the > port you've bound to.
Actually, that made me think of a possible reason: imagine that you have two different applications on the same device that want to speak the OIC protocol. The two can share the multicast port address (SO_REUSEADDR) and both can receive the multicast packets, as if they were separate devices. However, unicast needs to be directed at a different port, so that the two can be distinguished. If we're not going to receive unicast on the same socket that multicast will be received, we don't need the PKTINFO ancillary data at all. Unless, of course, CoAP has provisions for sharing the same port address with another CoAP stack, in unicast mode, and including packets with reliable delivery. I seriously doubt it can do that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
