Okay - that makes more sense now, and I agree on the feature.

The Transport shouldn't maintain state though (which @session for instance,
or @active) - those belong on the Session itself. It may be kind of a pain
to maintain some of the more complicated states though -
ActiveWaitingForHeartBeat or whatever. Maybe they're states of a object
that belongs to State? Hrm.


On Fri, Dec 6, 2013 at 12:25 PM, Kacper Kawecki <notifications@github.com>wrote:

> In lib/sockjs/transports/websocket.rb:
>
> > @@ -129,11 +135,38 @@ def extract_message(event)
> >          SockJS.debug "Received message event: #{event.data.inspect}"
> >          event.data
> >        end
> > +
> > +      def heartbeat_frame(web_socket)
> > +        @pong = true if @pong.nil?
> > +
> > +        #no replay from last connection - susspend session
> > +        if !@pong
> > +          @session.suspend if @session && @active
> > +          @active = false
>
> Sending the heartbeat response without a request will do nothing. Basicly
> mechanism which is implemented here work like this:
>
> there was response from previous heartbeat?
> YES - send a new heartbeat
> NO - suspend session (session is idle, but not closed), send new heartbeat
>
> heartbeat response received from client
> set that it was received
> set session active if session was suspended
>
> So the heartbeat response will never close the whole transport
>
> I was trying to do the mechanism which is added to new faye on client side
> - you have event transport:down and transport:up
> Which are telling that for a moment there is no connection, but websocket
> session wasn't closed (for example when you lost internet connection for a
> moment).
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/nyarly/sockjs-ruby/pull/7/files#r8172638>
> .
>