From: Luke K. C. L. <lk...@lk...> - 2005-10-02 22:20:42
|
hi, i've just added in the beginnings of a socket abstraction layer, it's full of the usual: pointers to function tables _again_ :) the reason for doing this is because it's a darn sight easier to mess with something that emulates sockets (behind an int) than it is to mess with the ncklib transport and com code. so it will be possible to put NamedPipes, shared memory, netbios etc. all in _userspace_ not having to rely on the kernel providing socket support for anything (of course the tricky bit will be emulating select and listen but i feel confident that people will be up to the task :) so! invent your own sockaddr_burbleburble and associated functions. i'm advocating using the socket integer as a means to lookup in a table - for whatever purposes. starting with a lookup table to locate the socket functions associated with that socket, and rpc__socket_open() and rpc__socket_close() will "hide" the fact that that's happening at all. i tried doing it differently - changing rpc_socket_t from an int to a struct, and got into an awful mess: maybe some day i will try it again, but i believe there to be some assumptions somewhere in the code about rpc_socket_t being an int rather than an opaque type and i haven't been able to track them down, yet. basically, rpc__socket_open() does a lookup into the protocol sequence table for your socket epv (end point vector) functions. i've added bsd socket epv (the contents of comsoc_bsd.c) already to rpc__ncacn_init() and rpc__ndadg_init(). if you want to invent your own transport, e.g. namedpipes, you will need to get rpc__ncacn_np_init() to "point" to your emulated sockets vector table, and everythink is hunky-dory. l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> -- |