Revising my previous work with Structured Networking code, I have been exploring the possibility of coding a unified socket engine which supports all five 'Socket Types' (w.r.t. the Semantics of the socket).

After some digging around, I realized that I can replace my WSASend and WSARecv functions with the UDP equivalents (WSASendTo and WSARecvFrom) - and simply pass NULL for the two extra parameters when the socket type is SOCK_STREAM (tcp).

What I am saying is that the UDP version of send/recv api functions work for ANY socket type... which is not true for the TCP version of these api.

Has anyone else attempted to write a unified socket engine, and if so, did you stumble apon this same solution path? If not, how did you proceed?

Posted on 2009-10-02 21:28:48 by Homer
I can confirm, happily, that this technique works  :thumbsup: :thumbsup:
Better yet - the 'extra parameters' are completely IGNORED when these calls are made apon tcp streaming sockets... we don't 'need' to pass NULL, we can pass anything we like here.

NetComEngine has been upgraded.
New methods!

RawConnection    - returns an initialized NetComConnection object using the given Socket Type.
CloseConnections - closes all NetComConnections (listening sockets are not part of this group).

I expect the new files will be made available (via Smart Updater service) as soon as Biterider has had a chance to play with the new code and look over the implementation nuances.

Posted on 2009-10-05 01:59:49 by Homer
As you know I deal more in the *nix side now but in network programming in general the sendto/recvfrom are designed for sending raw packets of any kind. if you want to use these for TCP, you can, UDP, fine, ICMP, no problem. You just have to implement the protocol headers yourself. If you remember that C tutorial I wrote back in the stone ages (lol) it detailed how to write a FIN scanner on linux through sendto/recvfrom. As for the WSA* variants, I found early on that windows versions tend to act in much the same way as the BSD networking functions. This is probably due to the fact that the windows network interface was based on Berkeley's BPF which is used on all BSD systems. AFAIK you can expect this behavior to be pretty portable throughout all current and future versions of windows.
Posted on 2009-10-07 08:20:10 by Synfire
It is gratifying that in a world of crap coding, we can rely on Microsoft to rip something off correctly.
What excites me is that this solution works under Microsoft's IOCP socket model, which easily handles tens of thousands of concurrent connections under a handful of worker threads.
What confuses me is that this solution is not clearly labelled, there is no example of this.
Posted on 2009-10-07 10:51:04 by Homer