apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: More migration of code from httpd to apr-util
Date Tue, 12 Jun 2001 12:26:53 GMT
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

Mime
View raw message