104 lines
3.2 KiB
Plaintext
104 lines
3.2 KiB
Plaintext
|
Can we provide (in the NSP timeframe) a generic URI-based IPC mechanism for
|
||
|
|
NT5 (and, in future releases, NT4 & Win9x)? More importantly, can this
|
||
|
|
mechanism be leveraged by UL?
|
||
|
|
|
||
|
|
The goal here is to totally separate the "listening" and "dispatching"
|
||
|
|
functionality. We'll provide a general IPC mechanism that everyone can
|
||
|
|
use. It just so happens that three of the customers will be a) the listener,
|
||
|
|
b) the worker processes, and c) the WAS.
|
||
|
|
|
||
|
|
Consider a completely stateless IPC mechanism based on only three APIs:
|
||
|
|
|
||
|
|
ULONG
|
||
|
|
RegisterUri(
|
||
|
|
OUT PHANDLE UriHandle,
|
||
|
|
IN HANDLE ParentUri OPTIONAL,
|
||
|
|
IN PWSTR pUri,
|
||
|
|
IN ULONG Flags
|
||
|
|
);
|
||
|
|
|
||
|
|
ULONG
|
||
|
|
SendMessage(
|
||
|
|
IN HANDLE UriHandle,
|
||
|
|
IN PWSTR pSourceSuffix OPTIONAL,
|
||
|
|
IN PWSTR pTargetUri,
|
||
|
|
IN PVOID pData,
|
||
|
|
IN ULONG DataLength,
|
||
|
|
OUT PULONG pBytesSent OPTIONAL,
|
||
|
|
IN LPOVERLAPPED pOverlapped OPTIONAL
|
||
|
|
);
|
||
|
|
|
||
|
|
typedef struct _MESSAGE
|
||
|
|
{
|
||
|
|
ULONG SourceUriLength;
|
||
|
|
ULONG TargetUriLength;
|
||
|
|
ULONG DataLength;
|
||
|
|
ULONG Reserved;
|
||
|
|
|
||
|
|
// WCHAR SourceUri[SourceUriLength];
|
||
|
|
// WCHAR TargetUri[TargetUriLength];
|
||
|
|
// UCHAR Alignment[varies];
|
||
|
|
// UCHAR Data[DataLength];
|
||
|
|
|
||
|
|
} MESSAGE, *PMESSAGE;
|
||
|
|
|
||
|
|
ULONG
|
||
|
|
ReceiveMessage(
|
||
|
|
IN HANDLE UriHandle,
|
||
|
|
OUT PMESSAGE pMessageBuffer,
|
||
|
|
IN ULONG MessageBufferLength,
|
||
|
|
OUT PULONG pBytesReceived OPTIONAL,
|
||
|
|
IN LPOVERLAPPED pOverlapped OPTIONAL
|
||
|
|
);
|
||
|
|
|
||
|
|
A request/response API can be built on top of these three primitives:
|
||
|
|
|
||
|
|
|
||
|
|
1. Process 1: Creates new GUID -> GUID1
|
||
|
|
|
||
|
|
2. Process 1: Registers "ipc:/GUID1" -> REG1
|
||
|
|
|
||
|
|
3. Process 2: Registers "http://foo" -> REG2
|
||
|
|
|
||
|
|
4. Process 2: Posts ReceiveMessage( REG2 )
|
||
|
|
|
||
|
|
5. Process 1: Creates request ID (another GUID?) -> RID1
|
||
|
|
|
||
|
|
6. Process 1: SendMessage(
|
||
|
|
REG1,
|
||
|
|
"RID1",
|
||
|
|
"http://foo/bar/xyz.htm",
|
||
|
|
{request_blob}
|
||
|
|
);
|
||
|
|
|
||
|
|
7. Process 1: Posts ReceiveMessage( REG1 )
|
||
|
|
|
||
|
|
8. Process 2: ReceiveMessage() completes with
|
||
|
|
SourceUri = "ipc:/GUID1/RID1"
|
||
|
|
TargetUri = "http://foo/bar/xyz.htm"
|
||
|
|
Data = {request_blob}
|
||
|
|
|
||
|
|
9. Process 2: SendMessage(
|
||
|
|
REG2,
|
||
|
|
"bar/xyz.htm", <- URI "stem"
|
||
|
|
"ipc:/GUID1/RID1", <- old source URI
|
||
|
|
{response_blob}
|
||
|
|
);
|
||
|
|
|
||
|
|
10. Process 1: ReceiveMessage() completes with
|
||
|
|
SourceUri = "http://foo/bar/xyz.htm"
|
||
|
|
TargetUri = "ipc:/GUID1/RID1"
|
||
|
|
Data = {response_blob}
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
08/23/1999 I don't think this totally stateless idea is going to work.
|
||
|
|
Well, it *could* work, but it places way to much burden on the
|
||
|
|
client & server writers to properly manage concepts like
|
||
|
|
keep-alive and dead peer detection. I'm now thinking we should
|
||
|
|
go to more of a handle-based mechanism with a sockets-like
|
||
|
|
flavor.
|
||
|
|
|
||
|
|
|