Replacing the whole socket interface of libcurl

I work on a project that uses libcurl, and even though it's by far the best multi-platform HTTP client library, several aspects of libcurl frustrate me. The biggest one is that libcurl demands that itself call most socket routines. This means that it can be very difficult to integrate libcurl's "multi" mode into high-performance applications with their own existing socket dispatching systems. This is particularly true in Windows.

It would be nice if there were a mode to have the application provide *all* socket routines, rather than libcurl calling functions directly. This is done with malloc (curl_global_init_mem), but not with sockets.

How things ought to work is that in a special mode, libcurl calls the application to request a socket to connect, specifying where to connect to and whatever other parameters. (Similarly, an API for requesting a listener for FTP and datagram mode for QUIC.) When the connection succeeds, or when data is received, or a bunch of other events occur, the application would call into libcurl with that information. Sockets would be mere abstract identifiers on libcurl's end, rather than always being an actual socket. They might as well be void *.

This would allow applications to use whatever socket dispatching mechanism it wishes. In fact, it would mean that the connections wouldn't have to be sockets at all. This would be useful for testing.

In Windows, this design would permit using I/O completion ports with libcurl. The I/O completion port model is so different from the traditional select/poll loop design that it can't be used with libcurl, because libcurl expects to be able to call recv() itself.

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2019-11-18