Socketless Transport?

EDIT: Um, better title would be Portless Transport.

Hello,

I find it tricky these days to come up with a unique IP port number to use with various server applications that I write. There's no guarantee that what you choose won't conflict with someone else's software.

To this end, what I've been thinking about is a special service running on a single port, that you can query (via XML, seeing as the kids think it's cool) to find out what named/GUID services are available and then pass traffic for that service through that same port (like an aggregate).

Is there anything like this already available?

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.

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()...

Quote:

---

Originally Posted by SMurf

I find it tricky these days to come up with a unique IP port number to use with various server applications that I write. There's no guarantee that what you choose won't conflict with someone else's software.

To this end, what I've been thinking about is a special service running on a single port, that you can query (via XML, seeing as the kids think it's cool) to find out what named/GUID services are available and then pass traffic for that service through that same port (like an aggregate).

Is there anything like this already available?

---

Already available... I woldn't think so.

A few suggestions here...

1) Make the port numbers user changeable through a settings dialog.

2) Clients don't have to be on any special port number.
So long as they know where to find the server the server can derive their port numbers from the return address in the packet. Finding a free port is quite simple:

Code:

---

    while(bind(hSocket,&localadderess,sizeof(SOCKADDR)))
      { if (!Scan)
          return 0;
        SetHostPort(++lp,&localaddress);    // Port = Port + 1
        if (lp > (Port + 256))
          return 0; }

---

3) You can use a broadcasting technique.
The server can also use the dynamic port technique in #2 if it's listening for client UDP broadcasts on ip xxx.xxx.xxx.255 of the local node. Your clients can open their ports and then "broadcast" on the xxx.xxx.xxx.255 IP of the router/switch sending a special recognition code. Hearing the broadcast your server can then respond directly to the return address in the packet with an "I hear you message". The client in turn takes the server's IP and port number from this message to contact the server directly.

It's a bit confusing at first... but I've done this and it does work.

Quote:

---

Originally Posted by bithub

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.

---

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. :(