> Hi Luke, hi aaron :) > IMHO, it is important to keep local and remote semantics distinct. Local > and remote services (by services I mean any form of IPC) are inherently > different beasts. If we allow named pipes to handle both local and > remote connections under the same conditions (errors, assumptions, etc) > than we may run into serious problems with reliability, error recovery, > and we may even expose ourselves to security risks. reliability and error recovery are not the responsibility of the [remote] API.
all applications - all the good ones, anyway - that i know of that use namedpipes or dce/rpc, pass error handling up to the application, for the application developer to deal with. in dce/rpc, this is even negotiable!!! you specify in the idl file 'i don't want to receive network errors', and well, you don't! security. well, yes, as soon as you get into distributed applications, your security risks go up. i am familiar with a fair number of the kinds of nightmare situations that can occur, having discovered and reported on large numbers of them to microsoft, until it got boring, there were so many. so, it's fair to assume that i've seen enough [an implementation of remote named pipes - the one in NT - that passes a buffer size in three separate locations, used one of them to check the received write size against the other, and the third one was the one used to allocate the data that the other one copied into. and this all in kernel-space...] > If you really want to start handling remote named pipes, I am more in > favor of something like what Justin suggested. That is, perhaps adding > new functions for the specific handling of remote named pipes. if i was to insist, and people decided, um, well, we're not going to do it, 'cos luke's getting stroppy about it, well, then the most sensible thing for me to do would be to say, okay, go ahead: dunna bother me, and when - or more hopefully - _if_ it's noticed later it dunna do what's expected, well i help redesign. and if it works, well, it saves me some hassle and some typing! all best, luke. p.s. i now have three apache modules that are using code that could be used as an early version of the unix apr_namedpipe() code. i haven't been able to split them into separate directories, not least because they are only 300 lines each, but because the effort of putting them in separate directories and then creating a mini-library for them is not justifiable.
