On Mon, Jun 11, 2001 at 10:33:17AM -0500, William A. Rowe, Jr. wrote: > Ok. Here are the not-so-subtle differences. > > First, I understand 9x actually supports reading and writing to a named pipe > created on an NT/2000 machine, but they don't support them internally. And > they > are always blocking. > > Second, the naming conventions are entirely different. On win32, the name is > \\.\pipe\somepipename while on unix (if I understand it) any directory can > 'host' > a named pipe. On unix, my pipe can be apache2.0/connectors/foo, while on > win32 > it is all within that 'pipe' pseudofolder. On Win32, we can actually open the > \\somemachine\pipe\somepipename from either 9x or WinNT, but the blocking > features > change. > > All this implies a common support for 'flat' entries (no directory tree, or > the > caviat that the 'path' will be ignored on win32.) It implies one of; an > alternate > file open call, a 'open pipe' flag bit, or returning the handles on open. > > Which is also a requirement. When we call namedpipe_create, we have to > RETURN > SOMETHING! Win32 will create a pipe handle (not the same as the read/write > file > handle.) Every (NT/2000) machine could Create or Connect to get that pipe > handle. > But once that pipe handle is closed, the pipe evaporates, they are not > persistant. > > So some semantics change. We don't 'rm' a pipe when we are finished with it, > we just > close the last handle. And pipes on win32 carry a 'suggested size', but the > default > is a paultry 8kb. the reasons for this are historical, and to do with the fact that the implementation uses SMB [even on loopback, i believe]
on top of this meagre data size, you can add your own protocol that provides you with more data, and that has the added benefit of guaranteeing your communication and latency timing without clogging up the network. > If this is what we want to use, let's start talking about what api we want. > I'm happy > to propose the changes to the _namedpipe_ functions that will get this > working in the > next day or two on Win32. the basic functionality that i really need is to be able to do 'messages'. definition of messages: - send some data on a pipe, it is guaranteed to all be transferred. followed by: - receive some data from the pipe, even if the data received is zero bytes [yes, this _is_ important], and it is guaranteed to be all transferred, and the amount i am told that is being received _is_ received. i.e. on NT, TransactNamedPipe. on ux-dom-sock, this can be achieved by sending / receiving a 4-byte header indicating the size of the data to be transferred. even if that size (send or receive) is zero bytes, the transaction *has* occurred, which is communication in itself [hi, please put this in a local file, and acknowledge it by sending me back zero bytes to indicate that the transaction is completed]. i'm labouring the point, here, i'll shut up now. > > The only thing we can't do with named pipes today is communicate with > > different machines. IMHO, calling any cross-machine communication medium > > a named pipe is just going to confuse any unix programmer. Give it a > > different name. > > No, it effectively is a named pipe. They *really* don't differ all that much. > The differences are in the naming rules, and Win9x compatibility. > > Implementors are just going to have to accept that 9x aren't Operating Systems > in today's sense, but consumer appliances/gaming consoles, seconded! 9x is a 'program-running-program' where the people developing it burn out in 6 months, leave after 2 years MAX. NT is a mt-os where the people developing it stay with MS for an average of 8 years, most of them are now millionaires and are there out of a sense of responsibility and duty to develop the best OS they can. pick your poison... luke
