madari / go-socket.io Goto Github PK

on gnanderson's branch i have tried to do some a basic update
but it would be great if you could update the repository name to the package name socketio
https://github.com/gnanderson/go-socket.io/pull/1

It seems that even though you can set c.sio.config.ReadBufferSize to any size, the underlying transport buffers are still using the default 4096 buffer value? So as it stands, if you increase ReadBufferSize beyond 4096 and send a large message, you get a bufio: Buffer Full, which is unhandled and drops the connection.
I have been trying to work out a temporary solution where it checks for this error, and continues to loop and build the total amount until EOF. But mainly its been a hack.

Is this something that is going to be solved in the streaming codec with v0.7? Or can you see any clear solutions as it stands?
I was able to get my hack to work in the sense of allowing an unlimited size message, but obviously that is not desirable, and the value of ReadBufferSize should really set a true limit. Maybe there needs to be a MaxMessageSize or something, so the ReadBufferSize can keep being reused to build up the total message UP TO MaxMessageSize. If it exceeds that, it would send back some kind of socketio failure, or, i guess drop the connection still.

Socket.IO is on 0.8.4 now; the protocol has been upgraded quite a bit. Are there any plans to upgrade this library to match? Is there anything you could use help on in bringing the project up to date? I'd love to see if I could get this working on App Engine as an alternative to the Channel API. Google's App Engine team is really interested to see what happens if it can work, too.

Let me just start by saying thank you so much for this library. I am learning Go right now by porting a Message Server over from python (Tornado, TornadIO, ZMQ) to Go and I'm really excited by these bindings so far!

I'm hitting one of your Fix Me's in connection.go:265
c.sio.Log("sio/keepalive: unable to queue heartbeat. fail now. TODO: FIXME", c)

What I am doing is rapid fire throughput tests with a command line client. When I use only a single client, I dont hit this wall. When I run 2 concurrent connections, the messaging hangs on this for a moment and ultimately then finishes, returning these errors after all the queued messages have been delivered.

My question is mainly about what is really happening here. Does it have anything to do with the heartbeats being queued on the same channel as the messages, and they are saturating the buffer to where heartbeats cant get through? Or is it a matter of raising the queue length value?
Is it a situation where ideally the heartbeat needs to be suspended while there is actual activity?

Thanks!
-- justin

The example doesn't work. It looks pretty old, "http" is now "net/http", etc.

The latest Go update breaks make...

[james@love go-socket.io]$ make clean
rm -rf _.o *.a *.[568vq] [568vq].out *.so _obj _test _testmain.go *.exe cgo .cgo[12]. test.out build.out
[james@love go-socket.io]$ make
6g -o go.6 util.go servemux.go message.go config.go session.go socketio.go connection.go codec.go codec_sio.go codec_siostreaming.go transport.go transport_xhrpolling.go transport_xhrmultipart.go transport_htmlfile.go transport_websocket.go transport_flashsocket.go transport_jsonppolling.go client.go doc.go
connection.go:327: undefined: closed
connection.go:375: undefined: closed
make: *** [go.6] Error 1

do you know what is stopping us from making this compatible with socket.io 0.9 client?

let me know, I would love to help out.

thanks.