NamedPipes - cause massive reliability problems with services. what to _do_?

[Luke Kenneth Casson Leighton]

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/m…

please note the comments "it is possible for a client to connect in
between the CreateNamedPipe and ConnectPipe".

in other words, NamedPipes don't have any equivalent of "listen()".

this is a massive _massive_ problem, evidence of which
i first encountered with "rpctorture --processes=100
--repeat-operation=100", back in 1998.

out of 10,000 operations performed across 100 processes, about TWENTY of
those operations would succeed.

that's a success rate of 0.2%.

(anyone who runs a lab where 400 students sit down at the
beginning of a session and all log in to the same NT PDC will
tell you _exactly_ what they bloody think of windows and it's the
same issue)


the reason why there is such an abysmal failure rate was not clear to me
until today.

it's due - quite simply - to this delay.  if the server is particularly
overloaded (due to having to deal with, oh i dunno, say, a large influx of
incoming Named Pipe client requests) then the time delay between
CreateNamedPipe and ConnectPipe is increased; if some idiot decides
that the number of pipe connections is to be limited; if someone decides
that the number of threads is to be limited, then the server quickly
goes into meltdown.

if there is protocol proxying or authentication going on (as is the case
of SMB IPC$ providing MSRPC named pipes - ncacn_np for those people who
know what that is) then you _really_ are in trouble.


the question is: having access to the source code - in reactos - what
can be _done_ about this?

would it be reasonable to write - and use - a named pipes equivalent of
"listen()"?

alternatively, how in hell's name do you _deal_ with this sort
of thing?

l.




-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--