On Sun, Feb 15, 2009 at 9:43 PM, Juan Lang juan.lang@gmail.com wrote:
Hi Luke,
does this sound like a reasonable proposition - a mini SMB/wineserver protocol - for use for inter-communication between wine and samba in order to exchange named pipe traffic?
Well, I think we have to crawl before we can walk.
:) that's why i said "mini" smb / wineserver protocol, comprising:
[2-byte command] auth, waitnphs, setnphs, read, write [parameters] [variable-data]
which is incredibly incredibly simple, and would take ... what... 200 lines of code, to write?
setting the "auth" data blob to NULL _is_ "crawl before walk".
I think it's more important that we have a working local named pipe implementation before we start thinking about SMBs from Wine to a remote machine.
follow the chain, here... :) not least, to make sure it sounds reasonable!
well, the more i thought about how awful the "multiple socket-pair queue" design is, and the more i think about what's on the MSDN "CreateNamedPipe" page, the more i believe that a per-file-handle Mutex is utterly utterly essential.
and if you're going to do that [per-file-handle mutex], then you _can_ use that to emulate blocking-read semantics correctly instead of read(), select(), poll() etc.
_that_ means that you can do whatever you like - send headers down the socket, send lengths down the socket, do whatever-you-like-down-the-socket because there will be only one reader.
_that_ means you can get away with sending quote commands quotes.
the combination of sending "commands" and exclusivity means you don't have to have the multiple socketpair queue
and, while you're at it, it so happens that you can replace the socketpair() with a sockaddr_un pair (hooray!)
so, you get to write a simplified design that meets the requirements _and_ is well on the way to meeting the other requirements - being able to interoperate with samba.
Usually, having a specific app in mind really helps drive an implementation, too.
i like to think ahead. saves a lot of time and effort in the long run.
l.