Session Management and Mega-Proxies? 23
chicagothad asks: "I help
to run large internet systems for a few Fortune 500 companies. We are
running several clustered systems, comprised of both Microsoft and Linux
technologies. We have run into several problems with what is known as
a 'mega-proxy'. A mega proxy is a way that large internet providers
distribute their outbound traffic via a pool of IPs. AOL/Compuserve
is the largest example of this. We are having fits with session
management right now. Does anyone have any ideas on the best system
structure or design to manage these beasts or any other tips that may
be helpful?"
URLs (Score:2)
Re:URLs (Score:2)
Re:URLs (Score:3, Interesting)
Re:URLs (Score:3, Insightful)
Re:URLs (Score:2)
Re:URLs (Score:2)
Re:URLs (Score:2)
Except that the original problem is with megaproxies where (in my experience) no two requests come from the same IP.
Re:URLs (Score:2)
there are a few ways to do this (Score:2, Insightful)
Most web app enviroments provide this functionality either built in, or through a library, php and perl both do, and im fairly sure IIS/asp does.
this is one of those problems that has been solved a thousand times before, and chances are, someone else has done a better job of solving it than you will on your first try.
Re:there are a few ways to do this (Score:2, Insightful)
[...]if that fails, append it to the url. if that fails, you have a few options[...]
How, exactly, could appending it to the URL fail? I use this method in everything I do that requires session ids (since it avoids the extra code for cookie checking, and you can hide the ugly session URL behind frames), and haven't ever had it fail. I'm not sure how that would even be possible.
Re:there are a few ways to do this (Score:1)
Re:there are a few ways to do this (Score:1)
Re:there are a few ways to do this (Score:1)
Not all of us are that flexible, so we have to find alternatives.
What are you asking? (Score:4, Informative)
Basically, the problem is such:
Sessions are usually stored in RAM. Thus, the session only exists on one web server even if there are lots of web servers. To make sure that the right webserver gets the traffic, the client IP, destination IP, and (sometimes) destination port are hashed together to determine which server to go to. Because the hash is deterministic between requests, this method insures that if a user hits Box A, he will continue to hit Box A, provided these things do not change (that is - source IP and destination IP/port).
The problem with the mega proxies (and lots of other forms of NAT where there are multiple outgoing IPs) is that the source IP does change. Thus, the hashing technique described above fails. Cisco Local Directors amoung others do exactly this.
The solution I've implemented basically keeps the session information in RAM, although it does this through a middle-layer. If I get a session ID from a browser but can not find that session ID in my RAM, I put a querry out to the server farm network and ask, "Who has this?" Whoever has it transfers the session to me (transfer, NOT copy, as I only want one authorative copy).
You have to be careful of concurrancy issues while doing this, but if you are careful, it will work well and be extremely fast for the majority of users, as they remain at one IP for the duration of thier session. But it allows the possibility of a session migrating.
Another option is to use a central "session repository" like a database or special application server. These are almost always going to be bottlenecks, though.
I will say that this is not uncharted territory. The solutions to these kinds of problems are well known. If you are dealing with Fortune 500 companies, make sure your project is funded well enough to bring in some as consultants... This is a fundamental issue to get right, and if you have problems here, I suspect you'll encounter some problems later.
Translation: (Score:2, Funny)
I think they run Microsoft or Linux or something.
Can someone help?
Oh. AOL does something similar, I hear. Does anyone know how they make that work?
Please help.
Thanks, Bob.
-
@home... (Score:1)
Stuff tends to break with source IP based sessions (Score:1)
With more and more ISPs implementing proxy clusters and intercepting outbound traffic, this is a problem that is going to grow, rather than one which will go away.
If you insist on using the source IP as part of your session management, you might want to look at the HTTP_X_FORWARDED_FOR and HTTP_VIA headers, as these sometimes allow you to determine the original IP of the client before it hit the proxy. However, it's not failsafe - some ISPs anonymise the IP, and some proxies don't provide the headers. Where this information is provided, it is generally concatenated - so you can get the detail even where the user is passing through multiple proxies.
How does
How'd you get the job? (Score:2, Insightful)
I hate the nature of this AskSlashdot item (Score:2, Insightful)
Down on the farm... (Score:1)
by Marco Tabini
IIS and ASP provide several methods to track a user's session on the server. But when you have several servers running concurrently, you have to modify your approach.
URL :
http://msdn.microsoft.com/library/en-us/dnmind9
This suggests one way of doing it from a few years ago, which isn't to say it's the right way, but it should give you some ideas...