FAQs

Questions

1. Q1: How does the performance rate? - answer
2. Q2: How do I customize the ISP Session cookie? - answer
3. Q3: How secure is your component? - answer
4. Q4: What is the difference between version 5.5 (as of March 01, 2010) and 5.4? - answer
5. Q5: Is ISP Session leak free? - answer
6. Q7: Can ISP Session run on Windows x64 in IIS 32-bit mode? - answer
7. Q9: Who are your clients? - answer
8. Q10: How did you carry out the test? - answer
9. Q11: How can I get support? - answer
10. Q14: I like the LiquidCookie feature, but isn't it difficult to prevent a user clicking on 'back' and receiving a 'session expired' message? - answer
11. Q15: Is your cookie/URL encrypted? - answer
12. Q20: How does it work internally? - answer
13. Q22: How many and what types of object can be stored inside the ASP session? - answer
14. Q23: What is recommended: querying my database or storing an ADO record set in the session?- answer
15. Q26: Which data type(s) can ISP Session handle? - answer
16. Q27: Does ISP session rely on Microsoft's session object? - answer
17. Q44: Which third party DBMS do you use for Session Storage, MS SQL/Oracle or My SQL etc.? - answer
18. Q45: I'm testing ISP Session and found that the pages time-out why? answer
19. Q47: Does ISP Session support web gardens (IIS 6 and higher)? - answer
20. Q51: I cannot share my session cookie with another host on the same web farm, for example: http://test1.mysite.com and http://test2.mysite.com while I do have the Application("AD_DOMAIN") = ".mysite.com" setting. - answer
21. Q52: How can I share a session between a secure website and an unsecure website? answer
22. Q54: How compatible is ISP Session with ASP.NET (any version) - answer
23. Q55: Will you create a similar component for ASP.NET 2.0? - answer

Answers

1. A1: Simply great! The numbers vary because of hardware and software differences and improvements, but in brief: Create a simple ASP page with a small incremental Session counter. For a simple 64 bit system we measured 400 ASP page requests per second.
   
   One customer reported that he has average load of 7000 asp user sessions per minute on his web farm.
   Of course the performance is slower than the native session object but the scalability is much better. This means, for example, that a standard ASP solution could easily handle 100 users, but with 1000 users it starts to groan. In contrast, our solution would still be happy.
2. A2: For clustering sites with several hosts like www.yourdomain.com and news.yourdomain.com etc you need to set the cookie domain property in Global.asa, see Application("AD_DOMAIN") = ".yourdomain.com".
   Of course a sub-path on Application("AD_PATH") = "/yourpath" can to be set too if you need to share the session cookie with several virtual directories. For each shared ASP Application you should set the variables as explained in the 'Readme.rtf' document.
3. A3: Security is one of our most important goals with this component. The session tokens are generated on a random basis (1 on 3e+38) using an RSA session token.
   The token is sent to a browser as a cookie or inside the URL to maintain the session between the web server and user. Since a network sniffer can pick up any local HTTP traffic, SSL is the only viable option to make your HTTP traffic secure. Any other encryption without using a public-private key algorithm is vulnerable. Using any legacy hash mechanism, over HTTP, intead of HTTPS, would give you a false feeling of security.
   We should mention that you can buy the source code and compile it yourself if any other security concern would exist. Please read the license agreement before doing so.
   - Warning:
   Using session tokens inside a URL is slightly more unsafe than using normal 'temporary cookies' because temporary cookies are stored in RAM and expire after closing the browser. However, URL's containing session id's are valid after the user closes the browser as long as the timeout period did not expire. This is not an issue if client computers are not shared among different users.
   About internal security. ISP Session always uses length prefixed buffers. So is not sensitive to buffer overflows. The storage mechanism uses a binary format plus compression. So, without special tools, nobody can read persisted session data easily.
4. A4:
   • The SessionPing component has been dropped. ISP Session automatically 'pings' if no data has changed
   • The need for a third party database (ie. Microsoft SQL Server) has been removed.
   • It is tested and supported on Windows 2003 sp2 up to Windows 2008 R2
   • SETUP is simplified since no SQL database setup is required.
   • Compression performance has been improved.
   • native Support for ISessionObject and IVariantDictionary have been (re)added.
     This is ideal for legacy applications and a minimal code change when you would implement ISP Session
   • ISP Session 5.5 is a hybrid component. It uses both the best of unmanaged code and managed code
   • The code footprint for ISP Session is considerably smaller since it uses no third party drivers like OLEDB or SQL Native Client anymore. Therefore, the memory and runtime requirements therefore, are less strict.
   • 5.5 does not need SQL server and the state server uses considerable less CPU resources compared with 5.4 using SQL Server
   • Version 5.5 is not binary compatible with previous versions. If you want to migrate, please contact us.
   • In short, more tuning, less overhead.
   • 5.5 does not use a JIT pattern on persisted COM objects (such as ADO or DomDocument). At each page request, all objects which were stored in the Session will be reactivated at page construction time.
5. A5:We have done as much as possible tests to resolve leaks. The results are viewable (look at the horizontal private bytes line!) see this image
   _{The image shown here, does not represent a scalability benchmark. It was used only to find leaks. Also, IIS had been set to low-application protection, so we measured 'Inetinfo.exe private bytes'}
6. A7: Yes, ISP Session can. However, before built 5.4.0.113, SETUP did not prepare for such installation. If you download the latest version, SETUP will make the required settings. Still, older 32-bit ISP Session DLL (Csession.DLL) read the HKLM\Software\Wow6432Node\NWCtools node. The mentioned version, has been fixed to read the HKLM\Software\NWCtools node, even if the IIS application, runs in 32-bit compatibility mode (ie. the enable32AppOnWin64 setting is set to true).
   For a special price, you can upgrade to the latest, revisioned version. If you however, stick your your current release, you'll have to manually transfer the registry key values, to the first mentioned node.
7. A9: Our clients include Canadian Railways, slimfast (US), Intellipro (US), EDS (Germany), Accenture (US), EZprints (US), Innovative Process Administration (US), Cognisoft (UK), Promissor (UK), ABW Tech (UK), Federal Mediation and Conciliation Service(USA), Identex Ltd (UK), Lockwood Greene (US), Syntec (UK), Vodafone (Ireland), Coldwell Banker Prime Properties (USA), State Digital (UK), Computershare (Australia), Undernet (Latvia), C2Softare (UK) and many more.
8. A10: We ran long tests using a stres test tool (WCAT) to see how the memory line and performance line would behave. Our tests allowed us to identify and solve many problems (such as leaks). Our downloadable demos helped us check conformance and reliability.
9. A11: You can hire us. National borders are no obstacle. You can call us to make arrangements, or you can email any questions about the component. Most questions will be answered within a day.
10. A14: You're right. If you have set this feature in combination with the URL cookie, a user really is forbidden to click on 'back' or press Ctrl-R (reload). This won't happen when you use a normal cookie to keep the session because the browser will always fetch the new cookie and send it back to the server.
    This is one drawback of not using cookies. Unless you want to scare users with an occasional 'expired session' message, you'll have to choose a client-side solution for the 'back' or 'refresh' button using Java script. A common trick is to use location.replace("newurl.htm");. The replace function, which is available in IE 4 and NS 4 (or wherever), will prevent the browser history queue from being built!
11. A15: No, it is not encrypted. Even if we were to encrypt it, it would not prevent a sniffer intercepting the session token. Because SSL was designed to ensure secure traffic, it's better to implement SSL on your website if you want to protect the session token.
    But, maybe, your question is related to the question: 'is your session token, predictable?'
    No, it is not.
12. A20: We basically wrap a stream to serialize session data to or from, each time an ASP page is requested. The stream is unzipped and unpacked to a lightweight key indexed property store (or a dictionary), that can contain almost any type of data. When the ASP Page enters the destructor, the stream is compressed again and written to the state server using TCP Sockets. The database ensures that no concurrency trouble exists, by utilizing a so-called 'timestamp'.
13. A22: On our demo web server a persisted object with 160 kB data needs 30 ms to be fetched. Your web server and DBMS might show better numbers, but in general a small ADO record set needs about 2Kb. So be careful not to store too many objects in the session.
    Any class (ADO or FreeThreaded DomDocument) that supports IPersistStream or IPersistStreamInit can be serialized. See our sample on the subject on persisting a COM component written in CPP.
14. A23: We cannot say which is faster because it depends on your query. If your specific DBMS query is a heavy and demanding query that is required on more than just one ASP page, it would be better to store the query output in the Session.
15. A26: It is compatible for normal oleautomation compatible data and arrays plus the System.Int64 datatype (VT_UI8 and VT_I8). For objects it is not compatible. In view of the scalability arguments explained above, we choose non-compatibility for objects. In addition, only persistable COM objects are supported ie. they support either interface IPersistStream or interface IPersistStreamInit.
    Those objects that you want to store in the Session, must be single Session variables, so you cannot persist arrays of objects.
16. A27: The ASP Session component is independent of Microsoft's session object. For reasons of scalability, it would be bad practice to build a dependency between them. It is better that the Microsoft Session manager is switched off. You should not use them both.
17. A29: LogonUser does work when the ASP application is configured to run in-process. When you configure your ASP application to run inside a pooled application or out-of process, give the IWAM_Computer account the 'run as part of the os' right using the Domain Policy editor in Windows 2000. This right becomes effective after the web service is restarted and the AD synchronization is completed.
18. A36: Yes, the downloadable demo contains modified scripts that use Jscript. Events such as Session_OnStart and Session_OnExpired, however, cannot be supported.
19. A44: ISP Session 5.5 is using a custom binary database service. So there is no third party DBMS needed.
20. There is no single simple answer to this. ISP Session is very scalable, however, sometimes an environment, requires too many Session refreshes for the same session. This might cause lots of DBMS page locks. If this is the case, make sure, you don't use HTML frames and that you avoid Session.Transfer or Session.Execute (these are the compatible method replacement for Server.Transfer and Server.Execute).
21. A51: Using a HTTP packet sniffer, we found that IE 6 badly deals with cookies that include a domain property. (This property can be set using for instance with ASP with Response.Cookies("mycookie").Domain = ".domain.com") . IE would pile up the GUID cookie in the RequestVariables collection instead keeping one unique cookie. FireFox 1.0 does not exposure this behaviour.
    Work around 1
    Apply the CookieExpires setting in global.asa.
    Example
    Sub Application_OnStart
    'insert line below or uncomment it.
    Application("CookieExpires") = 20
    End Sub
    Drawback
    The cookie will have the .Expires setting which makes the cookie a persistent cookie on the client disk. Some users deny all cookies so you should include a test for browsers that deny persistent cookies for your web farm. Work around 2
    Design your network configuration in such a way that your Web Farm is accessable using one hostname such as 'www.yoursite.com'. Your smart router hardware or software should balance the traffic among the web servers in your webfarm.
    You could use Microsofts network loadbalancing for instance.
    Work around 3
    If you want to redirect to another website, but not using cookies (because of the IE bug) you can use the idea below:
    Session.ReEntrance = True
    Response.Redirect(Session.URL("www2.mysite.com"))
    We feel sorry for the inconvenience in this lack of Internet Explorer's behaviour.
22. A52: At first, you should know, that if you share an unsecure session with a secure session, you void the security of the https session, since a network sniffer, could retrieve the cookie and use identity theft on the https session!
    However, we have made ISP Session as safe as possible for you
    The steps to follow to share a session and to fix the security hole you create by sharing a http session with https.
    
    • In global.asa set Application("CookieNoSSL") = True.
    • Just before you redirect to https set Session.ReEntrance = True, this allows a browser to continue a session while the hostname or even the complete URL changes.
    • At the redirected page, you disable ReEntrance again by Session.ReEntrance = False. If you go back to http, you should repeat the same trick.
    • To fix the security hole of sharing secure between unsecure (and vice versa) you should set Session.LiquidCookie = True in Session_OnStart.
      Note that you should thoroughly test your site after setting this option. LiquidCookies causes a session key to be valid for just one page request, after that request, a new key is automatically generated and established with your browser! So if a browser misses just one request, the session is lost.
23. a47: Yes, you can configure your IIS 6 classic asp application, to utilise web gardens. ISP Session has no problem with gardens, since it is not affiliated to a process or a thread.
24. a54: ISP Session is an in-proc, leight weight COM+ component and can run in interoperability mode with .NET. So, if you are at the process of converting classic asp to ASP.NET, ISP Session would be ideally.
    However, ISP Session is not yet a 'native' .NET replacement. So, ISP Session is not recommended for 100% native ASP.NET projects but just for interoperability between asp and asp.net.
25. a55: We have received a few requests but there seems no such market that justifies an investment to create a native-full-featured .NET equivalent that performs better than the built in one. If you need session state in an ASP.NET 2.0 environment, we suggest that you stick to the built in engine and optimize pages by using the readonly attribute for instance.