Just to be clear, there is a difference between "server state" and "per-user state". The former is generally an order of magnitude or three smaller than the later.
Let's consider the example of ebay. While not intimately familiar with the details of ebay's architecture, I've read their whitepapers (google "ebay scalability" if interested). Anyway... There are two options -- probably more -- but two basic options if you think about a paged ebay search result. First option, traditional "servlet session" style state management. User performs a search, that search result (or a reference to it) is stored in the user's session, along with a "current page" or "current item" indicator. When the user "pages" forward, their session state is updated to reflect the current page their on. This has two big implications. One, search results are unique to each user -- a massive storage requirement for millions of simultaneous users. Two, session state is frequently updated and because it's replicated for failover is creates massive "back channel" chatter. Ebay *used* to have this architecture. It crushed them and they had to re-architect. Second option, recognize that users search for the same kinds of things: "ipod nano", "macbook", "oakley". Store/cache search results and share them between users. Use a URL parameter to determine what page to show a user, rather than keeping track on the server of what page they are on. Go to ebay and perform a search for "ipod", you'll get a URL that looks like this: http://shop.ebay.com/items/__ipod?...&_pgn=1 First tip they are using a cache is the __ipod in the URL. Second, you can see the "paging" parameter on the end of the URL. If you go to the next page of the result, _pgn will be 2. Clearly, ebay is not "completely stateless". It has to store/cache search results. However, these are not "per-user". Ebay is stateless with respect to "user state". "Who you are" is handled by a cookie. But if you look at your ebay cookies you'll see one called "nonsession". :-) Maybe a joke on their part, but it reflects the reality. Certainly you can maintain a hash of "nonsession" to true user identity in the server. Maybe you would consider this "user state", but I don't. There is a big difference between that kind of state (to validate identity) and storing navigation position, history, preferences, etc. in the server. Ebay jams about 15 cookies down your throat so they don't have to keep that stuff in their memory or replication it across servers. Hope that clarifies the approach somewhat. -Brett On Jul 7, 4:46 am, ytrewqsm <[email protected]> wrote: > Thx brettt > > So stateless mean no usgae of servlet http session ? > > Since assume the following scenario : > > A user does some query that is based on some query paramter he has. > Then the result is dispalyed in pages on client side. in 100 / page. > (but the results are huge 10000) > On server side there has to be a cache or soemthing that "remember" > the results of that query to display the next 200 and so on > So a the server still has a state no ? > > Do i miss somenthign ? > > Or each time the server will execute a queryu to get first 100 then > next 100 and so on ? > > On 6 Iul, 12:11, ytrewqsm <[email protected]> wrote: > > > > > My plan is not no make another facebook :) is just a small erp. > > > that initially will run into a VPN but i would like to expose as a web > > app in the near future. > > > I uderstood the advandatges of keeping the server > > stateless ,security,failover since session are not going to be > > replicated from fasiled server and so on. > > > BUT :"The only way to be *completely* secure is to encrypt all wire > > traffic" > > > How can i do that ? > > > What are the drawback on this except a little bit slower application ? > > > Thx a lot for prev answers to all of u ! > > > On 6 Iul, 10:23, "brett.wooldridge" <[email protected]> > > wrote: > > > > It really depends on your application. If you have 100 simultaneous > > > users, > > > sure go ahead and use server sessions. If you are designing the next > > > gmail, ebay, or facebook, then server-side conversional state is a > > > HUGE > > > scalability mistake. Ebay, for example, is [almost] completely > > > stateless > > > (on the server). > > > > For security there are many options. One of the most common is for > > > the > > > server to generate a security token of some sort during login that is > > > returned to the client. > > > > Google (at least the Google Wave guys) would probably say using a > > > cookie > > > to pass it back to the server is a mistake -- pass it on every RPC > > > instead. > > > This can avoid some cross-site scripting attacks. Remember, cookies > > > are > > > automatically sent by the browser to the server. If you pass it by > > > RPC, then > > > YOU control when/if it is sent. But really, that part is your call. > > > The principal > > > is the same. The server can validate (yes, on every call) whether the > > > security > > > token is (still) valid. This is no costlier CPU-wise than a servlet- > > > session > > > lookup, and the memory reduction costs and fail-over advantages are a > > > big > > > win. > > > > Using servlet-sessions is no more (and probably less) secure. With > > > typical > > > server-sessions when a user authenticates (presumably over SSL) a > > > cookie > > > is returned. That cookie is all that is required to access the > > > session-state > > > on the server. Unless every request is encrypted, it passes in the > > > clear. > > > So, in the end, the more "state" you can keep on the client, the less > > > susceptible it is to access by an attacker. > > > > The only way to be *completely* secure is to encrypt all wire > > > traffic. Short > > > of that, there is no security advantage of server-sessions. There are > > > in fact > > > more disadvantages, as noted, due to the accessibility of server-state > > > given > > > knowledge of the session cookie. > > > > As an aside, you can theoretically mutate the security token upon > > > every > > > request, this avoiding a "replay" attack and "out-of-sequence" > > > requests that > > > indicate a man-in-the-middle attack can be detected. In general, that > > > kind of > > > security is completely overkill. If you're writing a banking or > > > financial > > > application, just use SSL and be done with it -- rolling your own > > > security is > > > likely to have holes and attack vectors you never imagined. > > > > -Brett > > > > On Jul 3, 1:59 pm, ytrewqsm <[email protected]> wrote: > > > > > I read this on with several ocassions while reading about GWT. > > > > > Now can anyone clear this for me ? > > > > > 1)What this means that on server side is recommended not to use > > > > servlet session ? > > > > > 2)How can i secure the application if the client only has state and > > > > server is stateless ? > > > > > 3)BTW Each time i pass credential on method calls ? Is that not > > > > something insecure ? > > > > > 4)How can those be passed securely ? > > > > > THX- Ascundeţi textul citat - > > > > - Afişare text în citat -- Ascundeţi textul citat - > > > - Afişare text în citat - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
