I doubt there is something like that available since it requires the back-end application and the client to specifically support this wrapper protocol that you would need.
I doubt there is something like that available since it requires the back-end application and the client to specifically support this wrapper protocol that you would need.
bit∙hub [bit-huhb] n. A source and destination for information.
Thinking about it, I can see a possible theory -- which may be severely flawed given that I have many questions.
Say you have a Base Application.
Base Application binds to Port. This application -- call it BA -- will handle all connections to that port and will be the app to which the queries will be directed. It will redirect all traffic from and to and servers/clients.
Server Application creates a file-socket (this is where I think most things might fail?) and notifies/requests Base Application to enable it to redirect traffic.
Server Application 2 does the same thing. Server Application N does it too.
Now, a client application will connect to BA's port. Then it sends an ID to state what it wants to connect to. What BA does is keep a list of clients and their respective 'servers'. Then, when it receives data, it forwards it to the server, and the same goes for whatever the server writes to a file-socket.
So, my real doubt (should investigate that) is if using sockets with files works as regular sockets and enables most operations, which I'm guessing not, throwing this idea down the drain.
However if it is possible to do such a thing in user-mode, then I think that "yes" would be the answer to your question. It's actually a pretty exciting project to me!
Is that possible? I see possible failures with, for instance, accept()...
Hmmm, well it might be possible to get round that by supplying a compatible interface (your own version of ws2_32.dll in the case of Windows) that mimics sockets to an application but pulls the process name to identify the service and feeds the data through from the "real" socket.
The only problem I can see with this is that moving data into other processes requires a switch into kernel space. So you're doing kernel space processing upon initially receiving data on the real socket, then into user space to decide what to do with it, then kernel space to forward the data on. Probably too cumbersome for high performance apps. I've written an NT driver before but it wasn't a pleasant experience.