Implement Websocket API about mongoose

[kbranigan]

excited

[ooXavier]

That would be perfect for an implementation of live statics in my app : mooWApp Server

[cpq]

I've implemented a first iteration of the functionality.
To see an example, checkout the code, then "cd examples && make && ./websocket"
Go to http://127.0.0.1:8080

It is crude at the moment. Client has to create, read and parse websocket frames on it's own.
Suggestions on the API are welcome.

[gogoprog]

Thanks! I'll test it soon

[barisaksan]

Thanks, this functionality will sure help me a lot.

The example code closes the connection just after sending a reply.
What should I do to keep the connection open? Returning a non-NULL value results in an infinite loop.

[cpq]

Heh, that code wasn't supposed to have more than one round trip :-)

However, I've enhanced it and updated the example. Now it does two roundtrips, keeping the socket open after the initial message and closing only when "exit" message is received from the client.

Please let me know if it works for you. Again, as you can see in the example code, user must prepare and parse websocket frames. Mongoose has to provide a convenient API to do that, but I haven't come up with the nice API yet. If you have suggestions, please let me know.

[barisaksan]

works exactly as I wanted, thank you very much!

[tzeH]

Hi! Thanks for this, I really need sockets for low latency UIs. I found it only worked with firefox, when I changed

!mg_strcasecmp(connection, "Upgrade");

to

!mg_strcasecmp(connection, "keep-alive, Upgrade");

in static int is_websocket_request(const struct mg_connection *conn). Sure this in an awful workaround, but you see where it's heading :-)

[cpq]

Right, I see.
I've pushed
9313141,
which should make things better.

On Mon, Sep 24, 2012 at 12:10 AM, tzeH [email protected] wrote:

Hi! Thanks for this, I really need sockets for low latency UIs. I found it
only worked with firefox, when I changed

!mg_strcasecmp(connection, "Upgrade");

to

!mg_strcasecmp(connection, "keep-alive, Upgrade");

in static int is_websocket_request(const struct mg_connection *conn). Sure
this in an awful workaround, but you see where it's heading :-)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/27#issuecomment-8804074.

[kbranigan]

This is excellent! I've wanted this with mongoose for, maybe even over 2 years now.

For the API, have you taken a look at libwebsocket?
I was using that in tandem with mongoose to achieve what I needed.
(making it actually a pretty decent headache to maintain)

There are a few desires, such as broadcasting messages to all or to specific connected clients in some form of main program loop (I am using it for a websocket/webgl video game server) - which also requires maintaining long-term connections to thousands of clients. (well hopefully thousands lol)

Fixed message lengths - it seems you're limiting to 126 bytes, or am I interpreting the code incorrectly?

Another thing I'm noticing, which is similar to what libwebsocket does, is that the client needs to assemble the complete websocket reply, including the pre and post padding, in your case, reply0-1

Anyway, perhaps all of this isn't really inline with what you intended mongoose for, in which case I am truly thankful for what you've built as it is. I have incorporated this code in several of my personal projects - greatly preferring it to any of the more complicated solutions. I seriously appreciate your efforts.

[cpq]

Broadcasting can be easily done inside the callback by usual means: block waiters on condvar, wake them up on new message, send message.

There is no limitation on the message length in mongoose. There is a limitation in the example only. Mongoose code parses the frame and sets internal conn->content_len to the message length. Well, to be entirely precise, websocket's message length is uint64_t, and mongoose's content_len is int64_t -- two times smaller. In reality I think this is not an issue. As soon as mongoose code sets content_len, user's calls to mg_read will return new data until everything is read. The reason of the limitation in the example code is that I was lazy and didn't parse the frame properly (that would be a copy/paste from the mongoose's code), and left it that way until people suggest an API :-) This is also the reason that frames should be fully constructed in the user's code. I did not yet give enough thought to the good API.

[jmucchiello]

I think you just need a flag on the connection object that this is a websocket connection (or an enum for standard_connection, websocket_connection, external_connection (for user calls to mg_connection)). Then inside push() you can generate a websocket frame for websocket connections. Same thing for calls to pull(). On a websocket, it can read/verify the frame and strip it off for websocket connections.

Alternately, mg_write_msg and mg_read_msg defined as only working with websockets is another possibility, though that would still probably need the enum mentioned above.