What is the usage scope of Tokio?



I’m looking at Tokio as a candidate for re-implementation of a network deamon for a Unix/Linux system.
The original implementation is mostly C-based and the protocol is based on XDR. Backwards compatibility should be preserved.
I’ve already implented a hello world / proof of concept kind of thing based on the streaming server tutorial just to get some rought idea. Works quite well but I have a few questions:

Is Tokio the right library for this?

In this thread people say that Tokio isn’t something most people will use. This is frankly quite a shock for me - I thought Tokio was meant as a general-purpose async networking library. I don’t understand how most Rust users would not use that. Is there going to be some other library that most people would use?

One of the features of the existing imeplementation I am not so far able to re-implement in Tokio is DoS protection - in the original C implementation a token-bucket-based algorithm was used to decide when a connection should be accept()-ed. Can I do this in Tokio somehow?



It says people will not use it directly, opting rather for using things built on top of tokio.

Most people work on a level (or many levels) above of network.[quote=“vojtechkral, post:1, topic:9529”]
in the original C implementation a token-bucket-based algorithm was used to decide when a connection should be accept()-ed. Can I do this in Tokio somehow?

It seems that you’d need to modify TcpListener, and put your accepting logic in there.


I have to say I really dislike where this train of thought is going. Rust ain’t Python. It should absolutely be expected that people will want to do low-level stuff.

By the same logic we could say that most people aren’t programmer and wrap this thing up :slight_smile:

Maybe I should use MIO instead?

What do you mean? As in modify Tokio source code or derive the trait and have Tokio use that?


I am not sure on what level you want to work, but if I was a user of your code (and other rust code) I’d rather have something that works well with the ecosystem, not custom-built solution, so I’d suggest using Tokio.

You want something that implements a Future (more importantly: your users want that).
TcpListener does not provide any way to hook into itself, so you could copy it to create DosProtectingTcpListener,
and this could be used instead of TcpListener. Or you could implement your own entirely separately.


Well, I like the idea of using Tokio (so far), but this isn’t much of a concern since I’m writing a daemon, not a library :slight_smile:

Ah, okay, thanks, sounds good.


This does not conflict with what it’s replying to. Some people will be using tokio directly. Some people will be using libraries on top of tokio. The only real assertions being made are the size of those groups relative to each other.


Well, ok, it then depends what that assertion is used for. For example, if someone complains that Tokio is way too complex for them, they just wanna download some file over http, then obviously it makes sense to point out they shouldn’t use Tokio directly.

On the other hand if someone wants to implement a networking protocol as part of a daemon and says Tokio is too complex, they might have a point. I can’t yet tell whether that’s the case, I haven’t yet spent enough time with Tokio, but I have to agree the number of types is high and some of them aren’t exactly intuitive.

Then again, I’m not sure Tokio is meant for the sort of thing I’m doing.


This is just my 2 cents on the issue after using Rust for about a year, but it seems like there are some mixed messages regarding the difficulty of low-level programming in Rust. On the one hand, Rust is presented as a language that allows developers to do everything they can in C (even if it has to be done a little differently), and the tokio homepage claims that “Tokio makes it easy to implement protocols and program asynchronously.” On the other hand, questions like “Why is it so hard to do ‘X’ in Rust?” are commonly responded to with answers like “you shouldn’t worry about the difficulty, use a library instead.” I think this can be off-putting for the potential writers of libraries that others will depend on. 90% of the time the community is super helpful, but the “just use a library” response, especially when no library exists, seems dismissive of peoples concerns (I’ve never received that response, just see it pop up occasionally).

Sorry to go off topic, and I don’t mean to single out tokio, I’ve just been seeing a lot more of the “dismissive” comments since tokio 0.1 was released and more people are trying to use it.