There must be another way of doing this without changing gnrc_udp. Because this is somewhat beside the point of conn, IMHO.

The only way to keep gnrc_udp completely untouched would require to run conn or POSIX in its own thread which would be worse. I'm also unhappy with this dependency but without this patch sockets won't work properly.

On 23 November 2015 09:17:02 CET, Martine Lenders [email protected] wrote:

There must be another way of doing this without changing gnrc_udp.
Because this is somewhat beside the point of conn, IMHO.

---

Reply to this email directly or view it on GitHub:
#4327 (comment)

Join the RIOT
http://www.riot-os.org

Then we need a similar solution for conn_ip

This seems like a hack. @OlegHahm Could you elaborate on the problem?

This seems like a hack. @OlegHahm Could you elaborate on the problem?

If a library uses POSIX sockets (like ccn-lite or tinydtls) and calls recvfrom() it expects that packets are buffered in the stack. Hence, one can do something like

sendto(...);
do_some_computation(); 
recvfrom(...);

expecting to receive the response to the sendto-call even if do_some_computation() takes a long time. Since gnrc_udp cannot forward the pointer to the packet to anyone if noone is registered, it can only discard the packets (what is currently happening and makes POSIX sockets on RIOT pretty useless for porting) or queue the packets somewhere.

@cgundogan, what about the proposed solution in OlegHahm@65506e5 ?

@OlegHahm thanks, I get it.

This points to something that should be solved at the core IPC: decouple message endpoints from threads. That way conn_* could have it's own message queue and register that when *_bind()ing. I've got code lying around for that, but that will probably need time to get in, as it's at the heart of core/.

If this PR fixes posix sockets for now, I'd say, lets get it in.

I thought about it, too. This doesn't necessarily have to be a replacement for msg but can also be an alternative (maybe a good idea for a first step anyway). I'm thinking of something like lwIPs mboxes.

I agree that this is a workaround for now, but we would need a more generic (no pun intended) concept to solve this. However, if you agree to take this workaround for now, I would implement the missing RAW IP part and we can merge this.

@OlegHahm I am fine with your proposed enqueuing strategy. However: In case of multiple threads that use gnrc_udp with different ports it may be possible that a message gets dequeued before it is checked by the target thread and put into the queue afterwards. This can repeat and lead to starvation (if e.g. both threads call receive in a loop)

@cgundogan, probably you're right, but I guess this can already happen without this patch, if there's an RAW IP and a UDP socket opened. I think we need to find a better solution in the long run anyway.

As long as this woraround is somehow marked as such in the code I join the others and ACK it

Okay, will do.

Are you okay with these comments? Should I squash?

Hm, still don't know how to garbage collect enqueued datagrams?

on closing of socket?

Might be way too late. One may open a socket just for sending period packets without ever calling receive. I think the best way is to switch to a different data structure, e.g. a lifo, and call a timer based garbage collector.

Thanks to the discussion with @cgundogan in #4320 I came to the conclusion that this is actually not required if you do the implicit binding during the sendto() call.