one client, one thread?

[miketang84]

In rust and rust-websocket, how to keep the connection for each client persion?
if one client, one thread, can reach 10k connections in single server machine?

[cyderize]

One client per thread is probably not good enough for 10k connections. Many operating systems won't allow you to spawn that many threads in a single program anyway and will fail (although it might work in some).

It's up to you to design how to handle the connections, as this is beyond the current scope of the library.

I will do some experiments and see if I can find out more about handling large numbers of connections.

[miketang84]

great.

[miketang84]

for message in client.incoming_messages()
this client.incoming_messages will occupy one thread, is it?
if want to promote performance, maybe need to rewrite the incoming_messages model? or rust low level event model?

[cyderize]

Yes, receiving or sending messages always blocks the thread since Rust only has synchronous IO for TcpStreams. It's difficult to implement anything other than one client per thread at the moment, maybe in the future Rust will have better mechanisms for reading from multiple streams at once.

One client per thread in Rust will take up too much memory as it stands, so 10k does not currently seem possible.

[miketang84]

is this library possible? https://github.com/carllerche/mio
maybe we can build rust-websocket-async on top to mio. :)

[cyderize]

This may be possible at some point, but unfortunately mio does not currently support Windows (which is what I'm currently using).

If this library does end up supporting Windows, then I'll consider building on top of it, as it certainly does seem promising.

WebSocket is actually quite a simple protocol, so if you're using Linux, you might be able to come up with something yourself using mio.

[miketang84]

:( I am poor on Rust, familiar with it now, I'm a web developer, so, let me try something.

but, great news:
Currently, MIO only supports Linux and Darwin. However, Windows support will be coming soon. The goal is to support all platforms that Rust supports.

I am appreciated with your works.

[cyderize]

Yes, hopefully Windows support will be available soon.

Thank you for your interest in Rust-WebSocket. I'll have a look at how mio works and hopefully there will be some way to get better performance.

[miketang84]

after looking into mio's realization, I think that I can try to replace's rust-websocket's low layer with it.
Let me try it under linux now.

[cyderize]

Yes. It should be possible to do this. Please let me know if you succeed.

I would try it myself, if I were using Linux rather than Windows.

[zrneely]

I'm also looking into using this library, and I'd like to avoid the 1-to-1 client-to-thread model. It looks like Mio supports Windows as of version 0.5. @daogangtang, are you planning on creating a pull request?

@cyderize, what do you think a good asynchronous model for websocket connections would look like?

[chpio]

diesel-rs/diesel#399

[illegalprime]

@zrneely It is definitely a goal, it is on my queue but if you want to give it a go that would be cool. 😃

[bgourlie]

Since hyper is now using evented IO, does that mean that rust-websocket is too?

[illegalprime]

@bgourlie where does hyper start using evented IO? and if it does, then its not exposed as evented currently in the library

[bgourlie]

No idea, I made that comment 7 months ago and have lost all context. Something must have given me the impression that it did, but I don't know what.

[comtihon]

@illegalprime
Hi,
in hyperium/hyper#778 hyper switched to mio. And as for current master, there is no mio in deps, but I found tokio there. I guess, they switched to it as tokio desired to be faster.
Are you planning to switch to latest hyper?
One thread per client is not good architecture...

[illegalprime]

@comtihon yes we are currently planning on including tokio support, you can see progress on #111 and you can use that branch if you want. We will switch to the latest hyper when it gets published.

[illegalprime]

Also, one client per thread is not the recommended architecture for many connected clients.
One should .set_nonblocking() on the stream manually and do a poor man's event loop.
Obviously we want to do better than that, but it's not merged yet.

[illegalprime]

@comtihon @daogangtang @bgourlie @zrneely this crate now supports tokio, closing.

[miketang84]

nice work!