I am currently rewriting IPC functionality for cross-process and cross-session stuff in usermode. I understand the pros and cons of the currently available IPC methods and am looking to continue support of limited user accounts (LUA) so my solution can't involve enabling privileges that are not in a limited user's access token by default, since they aren't assigned they can't be adjusted by the process with minimal access rights. I currently realize unidirectional IPC through mailslots, this is fine and does what I need since it's for the local computer only and never needs any network travel so the fact that mailslots use UDP (which is connectionless and considered unreliable) doesn't concern me. The advantage of ancient mailslots is that there is no need for interprocess synchronization such as a mutex, semaphore or event since the receiving (server) process receives a private copy of the data during ReadFile operation making the work mostly effortless to implement and hassle free.
What does concern me however is reliable connection-oriented bidirectional communication. I am currently using full duplex pipes which work, however I am a little skeptical of them for a few reasons and just figured it would not hurt to ask for another opinion for alternate options. Does anyone have any suggestions as to what some other reliable options are? I'd use memory mapped files backed by the pagefile however in order to "see" the section in other sessions it needs to have a name in the Global namespace, which requires the enabling of SeCreateGlobalPrivilege so this is a no-go and deal breaker for what I require. LPC and (A)LPC looked promising however they are using mapped views for "large" messages internally and I've a feeling this will not work either for my specifications/requirements (untested since old LPC code I wrote years ago, though). My final solution must allow for 32-bit <-> 64-bit process communication. Thoughts anyone?
* Edit *
Also, should have mentioned this... If the proposed solution can avoid direct disk access (such as a DLL with a "shared" section to achieve this) I am extremely interested in hearing what anyone has to say, all the better. I know it's a tall order but I'd like to see if there is a true alternative to pipes is all when it comes to full duplex communication. Originally, I actually designed a top-level protocol to incorporate reliability into mailslots and needless to say it worked, but "it worked" means little to computer scientists since it left a lot to be desired when it came to benchmarking performance with 2-way communication. Main issue was doing this without admin rights, since forcing mailslots to play the role of client and server reliably was never the design or functional intention of Microsoft, since mailslots are one-way transport IPC mechanisms. In case you've noticed by now, I truly don't like the idea of pipes, since I am injected into processes such as Csrss (before it became a "protected process" in Windows 8.1) I try to avoid hanging, be it my fault or some other program. I think at this point if I am reduced to using sockets and TCP over loopback I will have to kill myself, the idea of having winsock loaded in critical processes doesn't sit well with me from a stability perspective
Best Regards,
Brock
What does concern me however is reliable connection-oriented bidirectional communication. I am currently using full duplex pipes which work, however I am a little skeptical of them for a few reasons and just figured it would not hurt to ask for another opinion for alternate options. Does anyone have any suggestions as to what some other reliable options are? I'd use memory mapped files backed by the pagefile however in order to "see" the section in other sessions it needs to have a name in the Global namespace, which requires the enabling of SeCreateGlobalPrivilege so this is a no-go and deal breaker for what I require. LPC and (A)LPC looked promising however they are using mapped views for "large" messages internally and I've a feeling this will not work either for my specifications/requirements (untested since old LPC code I wrote years ago, though). My final solution must allow for 32-bit <-> 64-bit process communication. Thoughts anyone?
* Edit *
Also, should have mentioned this... If the proposed solution can avoid direct disk access (such as a DLL with a "shared" section to achieve this) I am extremely interested in hearing what anyone has to say, all the better. I know it's a tall order but I'd like to see if there is a true alternative to pipes is all when it comes to full duplex communication. Originally, I actually designed a top-level protocol to incorporate reliability into mailslots and needless to say it worked, but "it worked" means little to computer scientists since it left a lot to be desired when it came to benchmarking performance with 2-way communication. Main issue was doing this without admin rights, since forcing mailslots to play the role of client and server reliably was never the design or functional intention of Microsoft, since mailslots are one-way transport IPC mechanisms. In case you've noticed by now, I truly don't like the idea of pipes, since I am injected into processes such as Csrss (before it became a "protected process" in Windows 8.1) I try to avoid hanging, be it my fault or some other program. I think at this point if I am reduced to using sockets and TCP over loopback I will have to kill myself, the idea of having winsock loaded in critical processes doesn't sit well with me from a stability perspective
Best Regards,
Brock
Accept nothing less than STATUS_SUCCESS
