[riot-notifications] [RIOT-OS/RIOT] pkg/openwsn: add sock_udp (#15310)

Francisco notifications at github.com
Wed Nov 4 10:57:06 CET 2020


> > Note that here I opted by adding the missing functionalities to the sock implementation as a patch, I could have also copied the implementation here.
> 
> I actually was thinking about this. Having a `sock` header here and there, I see some potential for future conflict. What if there is an API change to `sock` on either side? That would require quite some effort with regards to `openwsn` then.
> 
> Also there are already some divergences in their implementation and our API:
> 
>     * [`sock_udp_get_local()` is supposed to return `-EADDRNOTAVAIL`](https://doc.riot-os.org/group__net__sock__udp.html#ga1a0e4c3a85b42cfcdc2f016dd2c96c83) when sock has no local endpoint, [not `-EADDRINUSE`](https://github.com/openwsn-berkeley/openwsn-fw/blob/e2958a031ad50a6f3eeca3a98ad1ae85aa773a48/openstack/04-TRAN/sock.c#L181-L184).
> 
>     * [`sock_udp_recv()` does not check the local of the `sock`](https://github.com/openwsn-berkeley/openwsn-fw/blob/1b20367fd2fff53b4ae00e0511a5582645c879cb/openstack/04-TRAN/sock.c#L201-L228), and thus never [returns `-EADDRNOTAVAIL`](https://doc.riot-os.org/group__net__sock__udp.html#gad1030df9b925878c2bf678487a9c88f7). Likewise the remote is not checked with the actual remote in the packet (should return `-EPROTO` if wrong).
> 
>     * [`sock_udp_recv()` truncates the data to `max_len` instead of returning `-ENOBUFS` if the buffer is too small](https://github.com/openwsn-berkeley/openwsn-fw/blob/1b20367fd2fff53b4ae00e0511a5582645c879cb/openstack/04-TRAN/sock.c#L211-L213) (also not sure [the `memset()`](https://github.com/openwsn-berkeley/openwsn-fw/blob/1b20367fd2fff53b4ae00e0511a5582645c879cb/openstack/04-TRAN/sock.c#L222) is expected). For a truncated return on receive, there is [`sock_udp_recv_buf()`](https://doc.riot-os.org/group__net__sock__udp.html#gaabbd7a35b628f79eebef42886dc796e1) (which is not implemented).
> 
>     * [`sock_udp_send()` returns `-EINVAL`](https://github.com/openwsn-berkeley/openwsn-fw/blob/1b20367fd2fff53b4ae00e0511a5582645c879cb/openstack/04-TRAN/sock.c#L87-L93) when the [precondition](https://doc.riot-os.org/group__net__sock__udp.html#ga89562920ad89fe0e098fc989e3b064ec) is wrong instead of running into an assert or something similar, while an actual conditions for `-EINVAL` (if `remote->netif` is  wrong).
> 
>     * [`sock_udp_send()` does not check if the range of ephemeral ports might be depleted](https://github.com/openwsn-berkeley/openwsn-fw/blob/1b20367fd2fff53b4ae00e0511a5582645c879cb/openstack/04-TRAN/sock.c#L120) (returning `-EADDRINUSE` in that case)[https://doc.riot-os.org/group__net__sock__udp.html#ga89562920ad89fe0e098fc989e3b064ec].
> 
>     * [`sock_udp_send()` assumes there is a remote endpoint to the sock](https://github.com/openwsn-berkeley/openwsn-fw/blob/1b20367fd2fff53b4ae00e0511a5582645c879cb/openstack/04-TRAN/sock.c#L124) when no `remote` parameter is given. The function is supposed to check that and [to return `-ENOTCON` in that case](https://github.com/openwsn-berkeley/openwsn-fw/blob/1b20367fd2fff53b4ae00e0511a5582645c879cb/openstack/04-TRAN/sock.c#L124).
> 
> 
> Not sure there are more issues (unittests might reveal that), but those are the ones I found so far.

They implemented there `sock` api against ours, its exactly the same header. But in the future they could diverge that is true.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/pull/15310#issuecomment-721632517
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20201104/3cdee8d2/attachment.htm>


More information about the notifications mailing list