Engine.io does not expose socket.id?

[mark]

The id property is not mentioned in the server side documentation, and I see it is nulled just prior to the close event being published, meaning we need to stash it somewhere on our own.

1. Why not document it? Or should we create our own ID?

2. If it exists, why not make it persist through the close event? if the socket is re-opened it's fine to give it a new ID - but all this stuff should be documented.

Any clarity on this would be helpful.

Thanks,

Mark

[utan]

Are you using socket.io v1 ?

I stopped development because I believe is too early to try it out..
and beside engine.io and socket.io have me all confused, I don't even know what client js to server socket.io clien or engine.io client..
regards.

[Arnout Kazemier]

There's an id property on the socket. You can persist the id using the cookie option.

Founder: Observe.it

Lead Software Engineer: Nodejitsu.com

Twitter: @3rdEden

Github: @3rd-Eden

Skype: arnoutkazemier

Mobile: +31623254031

--
You received this message because you are subscribed to the Google Groups "Socket.IO" group.
To unsubscribe from this group and stop receiving emails from it, send an email to socket_io+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[utan]

Agreed, they need to make a new documentation because hunting for information it's not really fun when it can be found and one spot..
And beside when creating the documentation should be thinking in newbies too...

I am a bit stressed.

On Tuesday, July 23, 2013 6:39:49 AM UTC-7, mark wrote:

[mark]

Thanks Arnout.

Yup - saw the id property in the code, and also seen your use of it in Primus. I just need it for the duration of the connection including the close, so will just store it in a local var following the connection event. I just think that it should be clearly documented, and I also think it's a bit weird that the id disappears prior to the close event - but this should be documented too.

Cheers,

Mark

[mark]

Utan,

I used Socket.io 0.9 but that has just waaayyy too many issues to work around.

Switching my code to using plain engine.io

Just go ahead and dive in.

To be honest, after quite a bit of experience with socket.io I feel like it offers very little over engine.io

Just build your own reconnection logic, which you may want to do in any case (I found it to be a necessity).

If you need room broadcasts - that's also straight forward to do.

engine.io is really very simple to use, the API is very lean - just hoping it works as expected :)

I was also considering sock.js which appears very similar to engine.io, but that seems to lack more features - e.g. no built in heartbeat

Bottom line - I would recommend not to wait for socket.io 1.0, try with engine.io or sock.js

[Arnout Kazemier]

@mark

I agree with that, I gave up on reading documentation years ago. I now only read the source code of projects to see how they tick and work and what I can use for my own advantage. But what your describing is one of the reason why i've build primus. To get around these crazy issues and have an interface that just works, with all real-time libraries.

Founder: Observe.it

Lead Software Engineer: Nodejitsu.com

Twitter: @3rdEden

Github: @3rd-Eden

Skype: arnoutkazemier

Mobile: +31623254031

[mark]

@Arnout - interesting project, I will definitely take a serious look. How production-ready do you feel it is? How would you rate the experience/usability of sock.js versus engine.io under primus? And is it possible to disable auto-reconnect entirely?

[Arnout Kazemier]

@mark The project is stabilising, all the hard work (the framework integrations) have all be completed. We're currently rewriting all our real-time services and customer facing apps at Nodejitsu on top of Primus because it not only provides a uniform interface on top these frameworks. It also fixes bugs inside these frameworks making them much stable when they run under Primus than if you where to use them as stand alone frameworks. As for selecting the framework you want to use internally, that's still a hard decision you've got to make as a developer. 

I think that each framework has it's own strengths and weaknesses. Sockjs is really well written but doesn't do transport upgrading and is written in coffeescript which makes it harder to contribute to. On the other hand, engine.io does do transport upgrading to bypass firewalls, but has far less available transports. So it always boils down to picking what you as a developer like to use. Primus just makes this a choice it a bit easier as it doesn't matter which you choose, if you don't like, just change it with one single line of code.

As for reconnect, in Primus you can just disable that completely by setting the reconnection options.

Primus.connect(url, { reconnect: { retries: 0 }});

Hope this helps :)

[mark]

Yup - definitely helpful :)

Thanks!

[utan]

Hi,

Yeah I tried engine.io alone but it lacked boadcast methods and things that my code currently use in socket.io so I was told soket.io v1 would have engine.io build in and it will do all the connection on the background so I decided to try socket.io v1 to start updating my code..
But instead a grew stressed...
Maybe I should just create a new code based on engine.io alone and go from there.. would be more work in order to make methods like socket.io.. but its doable

regards