disconnection event has not emit about go-socket.io HOT 23 CLOSED

I noticed this too. There never is a "disconnection" send for some reason. Which I actually think is related to #31 and #37 because this pointer is still there although it's disconnected, and thus it crashes.

from go-socket.io.

I've got "disconnection" event dispatch only with manual socket close on the client.
Connection drop or tab close doesn't dispatch anything for server side.
Moreover, since "socket.On" method ( event listener ) takes a closure function with reflection, - it creates a memory leak which I couldn't manage to fix.

from go-socket.io.

I would really love someone looking into these issues because even the simple example doesn't work for me. Refreshing the page doesn't send a "disconnection" like it probably should. And as I mentioned in one of the referenced issues, so.BroadcastTo makes the whole Go application crash when I just send between two different browsers. It's really too bad, because I really would like to use v1.x of socket.io with Go, and this seems to be the only server side library available for it.

from go-socket.io.

Hi, I'm working on this issue now. It's because of go-engine.io not stable enough. I try to refactor it now. As I only can do this beside working hour, the process is slow.

The client is depended on go-engine.io client too, which is under working.

from go-socket.io.

Superb! Any idea how long time this might take?

from go-socket.io.

I have a hacky fix, but works for me.
it's basically revert a change, and add defer to neglect panic.
change is for this file https://github.com/googollee/go-engine.io/blob/master/conn.go (in go-engine.io instead of go-socket.io)

 }

 func (s *conn) Close() error {
+   defer recover()
+
    if s.t == nil {
        return nil
    }
 @@ -158,6 +160,8 @@ func (s *conn) nextWriter(messageType MessageType, packetType packetType) (io.Wr
 }

 func (s *conn) serveHTTP(w http.ResponseWriter, r *http.Request) {
+   defer recover()
+
    if s.t == nil {
        http.Error(w, "closed", http.StatusBadRequest)
        return
 @@ -196,6 +200,8 @@ func (s *conn) serveHTTP(w http.ResponseWriter, r *http.Request) {
 }

 func (s *conn) onOpen() error {
+   defer recover()
+
    resp := connectionInfo{
        Sid:          s.id,
        Upgrades:     s.server.transports.Upgrades(),
 @@ -217,6 +223,8 @@ func (s *conn) onOpen() error {
 }

 func (s *conn) onPacket(decoder *packetDecoder) {
+   defer recover()
+
    switch decoder.Type() {
    case _PING:
        if s.origin != nil {
 @@ -253,6 +261,9 @@ func (s *conn) onPacket(decoder *packetDecoder) {
 }

 func (s *conn) onClose() {
+   defer recover()
+
+   close(s.readerChan)
    close(s.pingChan)
    s.server.onClose(s)
    s.origin = nil
 @@ -260,6 +271,8 @@ func (s *conn) onClose() {
 }

 func (s *conn) pingLoop() {
+   defer recover()
+
    lastPing := time.Now()
    for {
        now := time.Now()

from go-socket.io.

Thanks @helinwang . I'll try to figure out how to make it right.

@Chillance hope I have time to continue in October. So busy these days. :(

from go-socket.io.

Thanks @helinwang for the patch! I just don't want to wait until October... Appreciate the work nonetheless @googollee .

Now, it seems only to be a problem with a missing: close(s.readerChan) there.. which makes sense from what I've seen...

from go-socket.io.

@helinwang I applied the patch and now it doesn't crash. However, I have problems sending between 2 different browsers on localhost... It seems to be send from javascript, but somehow nothing happens on server side. Is there some kind of limit connecting from the same computer I'm hosting from or what is going on here? It's weird, because it seems like both connections (firefox, chrome) seems to be there, but somehow the message is lost and never broadcast to the other browser.

I can mention that on rare occasions, I had it working, but I'm still not sure how I did that.

Does this work for you?

from go-socket.io.

Ok, did a few more tests and noticed that it's something with using Firefox! I tested using several windows of Chrome, and there it worked as expected. But with Firefox, messages are lost for some reason.

I never end up in so.On("chat message", func(msg string) {..} sending using Firefox, even though I emit from client (or so it seems).

from go-socket.io.

@Chillance hmm, maybe your version of firefox does not support websocket? hmm, i agree with you it's weird. I only tested on chrome :)
a easy way to debug is install charles proxy (http://www.charlesproxy.com/) and check the http traffic.

from go-socket.io.

I'm sure current latest Firefox 32.0.3 supports websockets... But as far as I can tell, polling is used anyway. This library have polling first, then websockets defined for which method to use.

And I tested just now, and there is something wrong going on when using Firefox. It's easy to test. I just notice that if I just use Firefox, I notice that the message never reaches the Go function that handles the message. (so.On("chat message", func(msg string) {..} ).

Using Chrome and Chromium it works without any change. But not in Firefox. Haven't tested in IE.

Can you test?

from go-socket.io.

googollee/go-engine.io#8 is related. @googollee isn't satisfied with the solution yet so it can't be pulled, but perhaps someone here can help out?

Without this fix, you get into trouble after a client subscribes to a room, then disconnects, and a message is broadcast to said room. It causes the server to crash, because the socket loop in go-socket.io never quits, preventing the deferred function from leaving all rooms.

Here's the reader loop that never quits:
https://github.com/googollee/go-engine.io/blob/be0330257c12b93b6b776b0e02796e42a2bdbed7/websocket.go#L69

This is because readerChan blocks forever:
https://github.com/googollee/go-engine.io/blob/9b1964079e35e631b87b8b903d7c9296daa4556a/conn.go#L119

from go-socket.io.

Seems blocking disconnect issue is more important here. I can merge @mtsgrd code first, then try to fix the read issue.

from go-socket.io.

Anyone got a comment on it not working in Firefox (most of the time, as sometimes I managed to get a message through having two windows open messaging each other). I also noticed that in Chrome it only works if I have "pollling, websocket" set. Just using "polling" didn't seem to work in Chrome for me for some reason.

from go-socket.io.

@Chillance could you open a new issue? seems it doesn't relate to disconnection event

from go-socket.io.

Will do. Any ETA on when you think you have done the refactoring (of engine.io) you were talking about? Possible a lot of issues related here will be fixed by it. Maybe even the odd Firefox vs Chrome I was talking about.

from go-socket.io.

@Chillance, I believe this fixes the unrelated polling issue: googollee/go-engine.io#9

from go-socket.io.

Ah, awesome! Need to test this, but it sure sounds like this will fix the odd behaviors with Firefox and Chrome. Seems to me that many issues are really engine.io and not socket.io...

from go-socket.io.

Well, that is awesome @mtsgrd ! I tested and just doing that small change, it finally works for me! Seems I have to use polling only though, but doing so, it now works sending using the example from and to between Firefox and Chome!

from go-socket.io.

Please merge googollee/go-engine.io#9. :)

from go-socket.io.

Hi everyone, could you try latest version? Please update go-engine.io which is the base of go-socket.io. And it fixed a lot of bugs like no disconnect event.

And if meet any issue, please open a new issue.

from go-socket.io.

Seems to work now yes! Just tested with a clean checkout. Thanks man!

from go-socket.io.