Possible model for an abstracted network API

How can we make an abstracted network API but clearly separate the concern of dispatching socket events to different parts of the application?

If we think of how select, epoll etc. work then the pattern is:

We call the polling function with a timeout
It returns with a list of sockets with:
- Write and Read events
- Error events (I guess?)

Here is one potential interface:

int NETpoll(
    NETloopHandle Handle, 
    COLvector<int>* pWritetList, 
    COLvector<int>* pReadList, 
    COLvector<int>* pErrorList,
    int TimeoutInMilliseconds);

Is that the right collection class? Not sure. Alternatives could be a linked list etc.

For the socket handle objects one would have an interface which is safe to use, where int’s are ids which the socket API can see if they are valid and make the API to use them safe. So:

int NETsocketRead(int SocketId, COLstring* pData);
int NETsocketWrite(int SocketId, const char* pData, int Size);
int NETsocketClose(int SocketId);
bool NETsocketValid(int SocketId);   // is the socket still open and valid?

So then how would one handle the problem of figuring out which socket id should be mapped to which application code? Well I think that is a problem which can be solved much later - after one has added in the SSL/TLS implementation. For testing out this API it’s fine for the unit test to assume just one type of socket. The key idea is to decouple the data we use to manage a raw socket and the data/callbacks we are using at the application layer to decide what kind of socket this is and what to do with it. Then we will be able to avoid the callback/lifetime problems we have with SCK.

Concepts

Possible model for an abstracted network API

Related pages