Re: new networking code, filenames/locations okay?

On Tue, Aug 29, 2000 at 10:03:32PM +0200, Sascha Schumann wrote: > You might want to post a full documentation of the API you > are planning for the first commitable version. The first thing I want to commit is hostconnect which I think is useful in itself, removing some duplicate code. The first simple version is enough to simplify fopen_wrappers. Then I need to implement timeouts to simplify more code without reducing functionality. Well, let me try to list my thoughts on the networking "API". Some very specialized things won't be possible using the API, for instance one can't set the socket options one wants before connecting since hostconnect also creates the socket. Also one can't bind to a spesific port when connecting. But I think the API will cover what we have today, and if we can cover 90% of the cases with the API and have the other 10% doing it the old way, that's still good I think. Some details are missing, but I feel like implementing things gradually and make sure things work before implementing the next step. I also think that the API should reflect what we need, and then extend it later if necessary. My goal is to make standard use of the socket API easier, simplifying the code outside our API, and removing a lot of duplicate code. I also want to introduce IPv6 without changing too much code. One good example is hostconnect, it's a very common thing to do so it makes sense to have a function for it. One can also later do improvements like trying several addresses both IPv4 and IPv6 without changing the code that calls it. The API should also make most of the other socket code independent of system spesific details like IPv6 or not, and what thread safe resolver functions are available. Here are the details I've thought of so far: To connect with TCP and also UDP when possible: int hostconnect(char *host, int port, int sockprot, int blocking, int timeout) host can be hostname which is resolved into one or more addresses or an address, or perhaps also a file path (UNIX domain sockets). If there are several addresses try one at a time until we connect. It creates a socket with protocol family depending on the family of the addresses and TCP or UDP depending on sockprot parameter. blocking specifies whether to be blocking or not, and timeout might indicate a timeout value (if non-zero). Need to work out details for blocking and timeout. Do we need to be able to send UDP on platforms that don't allow connecting? We have two choices, I'm not sure what's best. Alternative 1: int sendto(char *host, int port, void *data, int len, int flags) This will create a new socket each time, not so good. Alternative 2: int send(int s, void *data, int len, int flags) We don't need to implement send, but if we do it, we can hide the fact that UDP is not connectable on some platforms. The hostconnect can on those platforms store the socket and the destination parameters internally, and then use sendto on those platforms. If one always receives UDP on connected sockets, we don't need to think about it since recv has no address arguments. If we want to do it on non-connected sockets we have the same alternatives. Either a recv equivalent that uses recvfrom if necessary, or implement a recvfrom equivalent. recvfrom would be int recvfrom(int s, void *buf, int len, unsigned int flags, char *from) Using a string for from to allow for arbitrary address families. We might also want char *getsockname(int s) char *getpeername(int s) Finally we might want something like bind(char *host, int port, char *address) When it comes to resolving the main functions would probably be char **gethostbyname(char *hostname) returning a NULL-terminated list of strings of addresses, perhaps including a free function for the malloced memory. char *gethostbyaddr(char *address); Not sure what we should call all the functions, perhaps we should have a common prefix for all? Stig