Hi Peter, Thanks for chiming in. Actually I missread the code since chsk/close is handled on the client, but if course it is sent from the server, which is what I want. Thanks for clarifying. I don't mind it reconnecting (in fact, it's desirable for what I want).
Basically what I want to achieve is this: Connections get load balanced between servers If a server goes down, the connection is dropped, sente automatically reconnects, the new connection is load balanced to a live server This all works out of the box. The case I wanted to solve is: since connections are sticky while they are live, if a server is under heavy load and wants to hand some connections to another server, it needs to force the client to reconnect so it can get load balanced again. Both techniques mentioned above work for this, but since chsk/close is server sent, tha is perfect. So no rush on disconnect :-) Re: chsk/close potentially being removed in the future, perhaps a reconnect! (I can't think of a use case for the server telling a client that it's done with comms, definitely seems to be the clients job - it could ignore the server anyway and open a new connection) function can be added to the server that simply sends that event. This way if the event is later removed, this function can be updated and nobodies code will break. Since its a one-liner I can totally write it for you if you like ;-) Thanks again (to both of you) and thanks Peter for a wonderful library. On 25 Aug 2014 07:33, "Peter Taoussanis" <ptaoussa...@gmail.com> wrote: > Hi guys, > > > (sente/chsk-reconnect! <my-chsk>) to disconnect (and then reconnect) a > connection. > > Yup, you can call `chsk-reconnect!` from the client to reset its > connections. This is useful mostly for picking up possible session changes > after authentication, etc. > > There isn't currently a client-side `disconnect!` fn, but it'd be trivial > to add (GitHub issue/PR welcome). > > > > I think you can send :chsk/close: > > Yeah, Sam's right (thanks Sam!). The server can send a `[:chsk/close]` > event to a user-id to have all of those user's connections terminated. If > any clients are still active though, they'll just automatically attempt to > reconnect again. > > You'd normally send this event during the server's normal procedure to > logout+cleanup a user. > > > > It seems that both chsk-reconnect! and :chsk/close events will let the > client control its connection state, but there doesn't seem to be any way > for the server to do so. > > Note that the `[:chsk/close]` special event is issued from the server, not > the client. Reason it isn't documented yet is that it's still subject to > change and may actually be dropped in future. Any change to the current > behaviour will be listed in the CHANGELOG though. > > > > Still, I'd like the server to be able to sever connections, although its > not a big deal since I can have the server send an event to tell the client > to do so. > > Sure. One minor clarification: Sente intentionally decouples the notion of > connection status and intention. It'll never assume that a dropped > connection is _intentional_ - so it'll always try to recover. > > Connections come and go. It's the (higher-level) channel socket that you > must close to convey that you're done with all comms and don't want any > more connections. The (higher-level) channel socket can only be closed > intentionally, it won't ever close due to changing network conditions, etc. > > Clients can indicate that they're done with all comms with a > `(chsk/disconnect! <client-chsk>)` call. > > To do this from the server's end, the server may send some notification > event to a user's clients - and those clients may choose to honour the > termination request with `(chsk/disconnect! <client-chsk>)` calls. > > Does that make sense? > > So it sounds like the client-side `disconnect!` fn is what you want. Again > - issues/PR welcome! Otherwise will try get this in by Wednesday, just busy > juggling some urgent tasks. > > Cheers! :-) > >> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
