0

So, I have an HTTP 1.1 web server-ish thing running.

When a typical web client connects, I get a bunch of incoming connections, all at once. On a server, on a LAN, I can tell them apart, because they all share the same IP.

On the WEB, I have a more challenging problem, because their remote port may be coming from a router that has multiple, dynamically allocated web client ports sharing the same IP address. Unless these sockets SEND something, they're totally anonymous.

Anyway, I'd like to bundle all of the connections together into one logical class, and trivially identify them and attach them to the right 'thing', as they happen, so these connections can share common data and credentials.

As I say, on a LAN that I control, this isn't too tricky. Just key from the IP address, they'll all be 192.168.xxx.xxx, or 10.0.xxx.xxx, or whatever.

On the internet, the IP address may be any number of users behind a router, and the ports are relatively meaningless (to me). Being sequential doesn't seem to be any guarantee, since if two any users behind the same router connect at about the same time, they might get interleaved ports assigned, as their browsers open one socket after another. So once in a million, this happens, and that causes a problem a hundred times a day with web-scale traffic.

As I am typing this, I realize this may be a non-issue, as I'm doing mostly WebSocket stuff, and those other connections seem to be all about grabbing resources, which in my case are generally 'harmless'. But on a 'long poll' version of the app to support all those crummy, old browsers out there, this could be a problem. I have a unique identifier for them to send with their data, so I can tell which socket is 'the one from the game' (for now... but it will come from one of any number of sockets), but only after I've received my data from it.

So as an item of curiosity, do I understand my situation right, or is there something simple that I'm overlooking, that could make my life 'way simpler'. I mean besides abandoning hope and becoming Amish, or something.

HopelessBleakDespair
  • 1
  • 1
  • Why? You don't care who they are until they ask for something. Then you can just do the usual HTTP session cookie things. And the 'thing' you bundle them up into *is* the HTTP session. – user207421 Apr 07 '14 at 22:53
  • HTTP is designed to be stateless, so each request is its own world. If you need to retain state (like for an application), you'll need to figure out and support cookies. For what you're talking about, just a unique ID would probably be sufficient. – John C Apr 07 '14 at 23:04
  • Yeah, I basically use a session ID, and added it to more of the client. – HopelessBleakDespair Apr 09 '14 at 09:10
  • I do care: When clients on tablets and phones click 'home' and the game pauses, and eventually times out (in case they never come back), if the user didn't explicitly close the tab that the client was open in, ALL OF THE OTHER connections that the browser opened in the background would stay open, and be kept alive *indefinitely*. So if I don't get any request that establishes an identity on any of these 'extra' connections in a reasonably brief time, I just close 'em. – HopelessBleakDespair Apr 09 '14 at 09:14

0 Answers0