return status from #sendUTF() et al.

[dvv]

Hi!

I want to implement a kind of outgoing queue for WebSocketConnection. When flushing the queue, in order to proceed to the next element, I need to know whether #sendUTF() was successful. How do I do that?

update: grepping the code for queue showed you already have implemented the outgoing queue, but wiki says nothing. Would be great if you shed some light on this topic.

TIA, --Vladimir

[theturtle32]

Yes, I did implement an outgoing queue, but I realized later that the usefulness of this is dubious at best. As it happens, Node implements its own outgoing queue and will send data to the socket as fast as the client can receive it. It will buffer any additional data until the client is ready to receive it, effectively accomplishing exactly the same thing as what I implemented. It's a redundant layer. That's the default behavior when one uses Socket#write() without bothering to check the return value.

I'm planning on doing the next version of WebSocket-Node using a streaming API rather than a message-based API, and will build a compatible message-oriented API on top of that. With a Streaming API in place, it'll be more feasible to directly deal with the send buffer and transmission throttling.

[dvv]

Great news. I'm building a messaging server on top of WebSocketServer. You plan to spawn a branch for streaming API?

[theturtle32]

Cool. What kind of messaging server? When I'm ready to begin implementing the next draft and the streaming API along with it, I will create a draft-10 branch to house the current implementation, and then the master branch will continue to be the main development branch.

[dvv]

Here we go: https://github.com/dvv/connection -- example/websocket. Please, give some feedback. TIA

[theturtle32]

I didn't see a README on the page, and I'm not quite sure what I'm looking at from a quick glance at the code?

[dvv]

right, i'll try to compose a readme. the point is to provide cross-browser bidirectional high level messaging layer with acknowledgments, WebSocket-Node being a server

[theturtle32]

Ok cool. What are the acknowledgments needed for? In case the transport is lost and needs to be re-established?

Sent from my iPhone

On Sep 19, 2011, at 9:15 PM, Vladimir Dronnikovreply@reply.github.com wrote:

right, i'll try to compose a readme. the point is to provide cross-browser bidirectional high level messaging layer with acknowledgments, WebSocket-Node being a server

Reply to this email directly or view it on GitHub: https://github.com/Worlize/WebSocket-Node/issues/8#issuecomment-2141568

[dvv]

Drafted a readme: https://github.com/dvv/connection/blob/master/README.md

Acks are the way to use continuation-style programming. Compare: Fs.readFile('foo', function(err, result) { ... }) and conn.send('foo', argument, function(err, result) { ... }). When remote side is done with message, it can (should, in fact) report this fact to the caller. Connection#ack is a safe way to pass info back to the caller

[theturtle32]

Ah ok, so it's more like an RPC framework over websockets. Nice. Reminds me of dnode: https://github.com/substack/dnode

[dvv]

Yes. But without >=6 dependencies and with much cleaner interface, imho ;) I try to compose a transport-unaware browser-server intercommunication channel with messaging.