Skip to content

Optionally expect heartbeats from the server #67

Closed

Description

@majek

The server may send an option telling the client how often it will send 'heartbeat' frames.

We should read this option and, indeed, expect heartbeats. We should kill the session on a heartbeat miss.

Activity

  1. added 17 commits that reference this issue on May 18, 2012
  2. glasser commented on Sep 26, 2012

    @glasser
    Contributor

    There was a lot of activity on this issue but it's still open. Does the feature work (and it should be closed)?

  3. hyperthunk commented on May 14, 2013

    @hyperthunk

    @glasser I'm not 100% sure, but I'll discuss with @majek when I get a chance and either merge or close it.

  4. mokesmokes commented on Jul 23, 2013

    @mokesmokes

    Any update?

  5. triopter commented on Feb 25, 2014

    @triopter

    It looks like all of this was on a "dev" branch that never got merged. Is there any plan to merge this into master and release it?

  6. majek commented on Feb 25, 2014

    @majek
    MemberAuthor

    The fix was way harder then anticipated and required major changes to the codebase, and eventually I gave up. Sorry.

  7. 3rd-Eden commented on Feb 25, 2014

    @3rd-Eden

    If you use primus on top of sockjs it will send these heartbeat packages for you. From client -> server and the server will automatically disconnect if a heartbeat missing/timed out. See https://github.com/primus/primus#heartbeats-and-latency

    So if you really, this might be a viable option.

  8. triopter commented on Feb 25, 2014

    @triopter

    @majek that's too bad! We're testing out the "dev" branch with the heartbeats right now (it seems to be up to date w/ v0.3.4) and it appears to be working.

    @3rd-Eden Thanks for the pointer to Primus -- we'll definitely take a look at that!

  9. rikoe commented on Mar 7, 2017

    @rikoe

    Hi. This issue has been open for almost 5 years now. It was recently discussed in #297. Is there any plan to implement this feature? The client not being aware of the server disappearing from the network seems to be a major flaw.

    What is the "dev" branch mentioned above that has never been merged if one wants to take a look at it?

  10. harshakakumanu commented on Nov 30, 2017

    @harshakakumanu

    Are there any plans in implementing this issue? Is there any work around ?

  11. locked and limited conversation to collaborators on Aug 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions