Hi! I'm in the process of cleaning up the code in order to re-enable Windows compilation. I've found several things we'd need to unify somehow:
We have (until recently) had only TCP protocol support hence the calls like: Ns_SockBind Ns_SockListen etc. As of now, there are multiple other connection options supported (raw sockets, udp sockets, unix domain sockets). There are couple of places in the code where I see: Ns_SockBindUdp Ns_SockListenEx Ns_SockListenUdp Ns_SockListenRaw Ns_SockListenUnix I'd like to bring in some logic there. Therefore the proposal: All TCP related calls should stay as-is. We'd add additional calls to better identify what's being done: Ns_SockListenTcp (new, should be called by Ns_SocketListen) Ns_SockListenUdp (exists) Ns_SockListenRaw (exists) Ns_SockListenUnix (exists) Then: Ns_SockBindTcp (new, should be called by Ns_SocketBind) Ns_SockBindUdp (exists) Ns_SockBindRaw (new) Ns_SockBindUnix (new) In binder.c there are some calls which are only used withing the file hence we'd need to adjust the call interface to illustrate this: Ns_SockRaw - > SockRaw Also, the Ns_SockListenUnix is a combination of create + bind but unlike other pendants, does not honour the preboundUnix sockets. We should split this. Make the Ns_SockListenUnix actually honour prebound sockets (which it does not do now) and use internally the Ns_SockBindUnix to bind so it'd be on-pair with the TCP. All in all, this will not change the functionality but will *definitely* improve understanding and code maintenance. There are other places in sock.c which seem pretty odd like Ns_SockBind calls Ns_BindSock what is the reason of having those two (backward-compat?) I will like to cleanup this now. Are there any voices against or any other ideas? Cheers Zoran
