Re: [lwip-devel] Extended udp_recv callback

[Jakob Stoklund Olesen]

Kieran Mansley wrote:
> I think a combination of the two approaches might be best:
>  - add an extra callback to the API, something like pcb->recv_ext() with
> an associated means of setting a handler for this callback. 
>  - have a pcb->flag that selects whether to use the normal recv callback
> or the extended recv callback.
>  - have a compile time EXTENDED_RECV_CALLBACK definition that can be
> used to compile the extended recv callback feature out if others don't
> want it.
> 
> That way existing code doesn't need to be modified as the old callback
> remains the same.

I like this. Let me write a patch and get back to you.

I will do something like this:

#if UDP_EXTENDED_CALLBACK
  if (pcb->flags & UDP_FLAGS_EXTENDED_CALLBACK) {
    ((udp_extended_callback_function)pcb->recv)(pcb->recv_arg,
      pcb, p, &(iphdr->src), src, &(iphdr->dest), inp);
  } else
#endif /* UDP_EXTENDED_CALLBACK */
  {
    pcb->recv(pcb->recv_arg, pcb, p, &(iphdr->src), src);
  }

Pointer-to-function casting is safe isn't it?

> I feel a bit like this change shouldn't be necessary though.  I'm not
> opposed to layer violations where there's good cause, but normally when
> something like this crops up it's because something is being done in the
> wrong way and I'd rather fix that.  How would this application be
> supported in another environment?  E.g. what API is available for
> mDNSResponder in places where it works already that we don't have in
> lwIP?

The mDNSResponder code for Posix, Mac OS X, and VxWorks uses the
recvmsg() syscall and struct cmsghdr. I am not familiar with this API,
it looks quite complicated. See recvmsg(2) and cmsg(3).

The Windows code is similar, except you put WSA_ in front of everything.

I don't think we can do something like this for lwIP and still be
lightweight.

Actually a multicast DNS implementation is also required to check the
TTL of incoming packets. Packets are sent with TTL=255, and they must
also have TTL=255 on arrival. That way you are sure they have not been
forwarded.

I have not implemented this, and I don't really need it. But perhaps the
extended callback should get the entire IP header instead?

/stoklund