http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/mu...
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.
-
Luke Kenneth Casson Leighton