http://qs321.pair.com?node_id=800587


in reply to How to keep network connection persistent during session?

HTTP just doesn't work that way. Aside from that, even if you could serialize a network connection (which you can't) it won't help you do what you want to do.

If you want to use HTTP, the best easily achievable goal is to use Keep-alive on the connection (which AFAIK any decent webserver should support / suggest / do already by default, but it may help to test it and/or increase the timeout. This won't help you with the authentication part, since HTTP doesn't guarantee that single connections serve only a single session - it's even possible that in between proxies could "bundle" multiple sessions over a single connection (though I don't know of any proxy that does that).

In any case, IME if authentication/reconnection takes such a large part of your system, you're either doing it wrong, or you're not doing anything very interesting.

If you're really that pressed for processing power, switch to a protocol that's a little less designed for single request/response actions and more designed for long-term connections. Like STOMP. Of course, that means ditching a pure web based approach...

"What should it profit a man, if he should win a flame war, yet lose his cool?"
  • Comment on Re: How to keep network connection persistent during session?

Replies are listed 'Best First'.
Re^2: How to keep network connection persistent during session?
by PetaMem (Priest) on Oct 12, 2009 at 08:15 UTC

    Hello Monks,

    thank you for your answers. I would like to clarify some things.

    • I'm using newest Apache2, newest mod_perl.
    • I do not need nor want to store the connections on disk. I would simply want that within a session a network connection is opened, and remains open as long as the session is active. Which means the network connections life should extend - of course - the life of the running apache processes that happen during that session. That's the whole problem.
    • The backend is not a DB, but an own server process (which uses Net::Server::Multiplex

    If it's going to be a "daemon brokering the connections", that's ok, I just thought Apache2/mod_perl2 would have something that persistent themself - shared memory perhaps? Some space all Apache processes are sharing for the lifetime of the Apache process? (I'd be willing to take into account that if the Apache as whole had to be restarted that the network connections would be lost).

    Thanks

    Bye
     PetaMem         All Perl:   MT, NLP, NLU

[reply]
      I'm using newest Apache2, newest mod_perl.

      That does not change even one bit in the HTTP protocol, so it is (nearly) irrelevant.

      I do not need nor want to store the connections on disk. I would simply want that within a session a network connection is opened, and remains open as long as the session is active. Which means the network connections life should extend - of course - the life of the running apache processes that happen during that session. That's the whole problem.

      Serialisation does not necessarily mean writing to disk. It just means to generate a string of bytes representing a complex structure. And you can't to that with a network connection, because you literally hold only one end of the connection.

      Basically, you want to extend the session handling to also manage a network connection. A naive implementation would use a hash, using the session ID as key and the file handle of the socket (network connection) as the key. Whenever you create a new session, you also generate a new socket, and store both in the hash. Whenever the session is closed or expires, you close the socket and remove session ID and socket handle from the hash.

      A better solution would be to separate connection and session also in the backend. If you use some kind of remote procedure call API, create a new session in the backend and get a handle (a simple, random number) back. Use that handle for all interactions during the session, and destroy the handle when the session is terminated or expired. Connect to and disconnect from the backend as needed.

      The backend is not a DB, but an own server process

      As most DBs are separate server processes, this is irrelevant, too. In fact, it does not matter if you connect to a DB server, an FTP server, or a coffee machine server.

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]

In Section Seekers of Perl Wisdom