Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
News

Session Management and Mega-Proxies? 23

Posted by Cliff from the complex-networking-issues dept.
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?"
This discussion has been archived. No new comments can be posted.

Session Management and Mega-Proxies? More

Session Management and Mega-Proxies?

Comments Filter:
  • Usually the best way is to hold the session key in the URL the user's using.
    • Two main problems with that: ugly links that you need to watch out for when people copy/paste/post them, and people bookmarking, again, need to watch out for what happens when a session key with no session is used, or worse, if a session key ever gets recycled.

      • Re:URLs (Score:3, Interesting)

        by Lally Singh ( 3427 )
        If you put a time-date stamp of the session key in the URL, then you solve the third problem. If you get a URL where the session has expired, a new one can be created immediately, and the user can be redirected into that session via all the links in the page they get back. That would also fix the copy/paste/post problem.

        • Re:URLs (Score:3, Insightful)

          by SuiteSisterMary ( 123932 )
          Still need to make abso-ma-loutely sure that session keys'll never ever be recycled. Also, make sure you don't store session keys, dates, stuff like that 'raw.' Either you or your server software should do fun things like hash them, so you can tell accidental or purposeful tampering.
          • A simple function converts a tuple of (session key, date) back & forth to a string you can put in a URL is pretty simple to set up. That way, the session key itself is never alone in the URL. And if you really, really want to be paranoid about it (in case the session keys can be used to access/modify sensitive information), you can attach a digital signature to the whole thing. i.e. (session key, date, signature of (session key,date)) is converted to a string that's put in the URL.
            • Also good to have the originating IP and the destination IP thrown in, for various reasons, the finding of which I leave as an exercise for the reader.
              • Also good to have the originating IP and the destination IP thrown in, for various reasons, the finding of which I leave as an exercise for the reader.

                Except that the original problem is with megaproxies where (in my experience) no two requests come from the same IP.

                • Or where ALL requests come from the same IP. Or they forget to set their damn proxy to NOT cache anything that happens to have the telltale 'dynamic content' characters in the URL, like '?' and '&' and get cached, and the request never actually gets to your server.
  • using a client IP as a session key is a horrible way to do session managment, very bad idea. generate a random(but unique) key to use, try to set it as a cookie, if that fails, append it to the url. if that fails, you have a few options, have a failsafe version of the site that works without session managment, or you can present the user an error message, or you can fall back to using the ip, the most common choice seems to be to present an error message saying something to the ffect of "for this site to work properly you must enable cookies in your web browser. this can be done by doing xyz in your browser.

    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.

    • [...]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.

      • one reason that could fail is if the client uses one of these proxies that arer supposed to increase security. alot of them have modes to block things that look like session keys.
        • Huh? How on earth does such a thing tell the difference between my session key and (say) Amazon's ISIN stock codes? Surely anyone using a piece of software like this is going to have a severly degraded experience of a lot of the web? Why not just kick yourself in the balls repeatedly and be done with it?

  • What are you asking? (Score:4, Informative)

    by jmaslak ( 39422 ) on Saturday December 22, 2001 @10:33PM (#2742908)
    What kind of problems are you having? Because you mentioned large organizations, I'm assuming you are talking about problems with large-volume web server farms and traditional session management techniques.

    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)

    by adolf ( 21054 )
    I push buttons on computers at several Fortune 500 companies for a living, and something about the "MegaProxy" gizmo doesn't work. Unfortunately, the $bignum that they pay me isn't sufficient for me to think of my own solutions.

    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.

    -
  • Look at the former rogers@home and don't do it
  • Putting my medium-sized-mega-proxy-admin hat on (some 120 million reqs/day), I'd suggest that you don't use the source IP as part of your session key generation or implementation. Things break when remote hosts depend on the source IP remaining constant.

    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 /. do session management? ;-)
  • Without knowing something so basic to web site operation?
  • Why should we (the intelligent users) tell you (the overpaid 'consultant') how to put together a good session-based system ? The information is readily available on the web for anyone to read, and it's not even that hard to find, assuming you know how to use a search engine such as Google. The solution is a hybrid of simple techniques which make up for each others' weaknesses. Just use that Fortune-500 brain you've been neglecting all these years.
  • "Maintaining Session State on Your Web Farm"
    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/dnmind99 /h tml/session1099.asp

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

Slashdot Top Deals

The hardest part of climbing the ladder of success is getting through the crowd at the bottom.

Close