Can Rama be used to create a non-async http client?

[nastynaz]

I need to write a low-level http client that uses fully-synchronous non-blocking tcp sockets without any use of futures.

I want to have full control of the packets so I can implement features like sending the payload except for the last packet and then finalising the request later by sending just the final packet.

Is this possible with Rama? If so, what primitives do I need to use? Any help is greatly appreciated.

[GlenDC]

I need to write a low-level http client

Very interested in help you achieve this with Rama :) Might already be possible to do so, and if not let's figure out together what you are missing and how to get there.

uses fully-synchronous non-blocking tcp sockets without any use of futures.

This is already possible and doesn't mean the rest of your logic cannot be asynchronous. These two worlds can be bridged. But it probably does mean you need to write some transport service or utility. All depends on what you need exactly. Something we would need to discuss if you can give some more details.

I want to have full control of the packets so I can implement features like sending the payload except for the last packet and then finalising the request later by sending just the final packet.

This is possible but depending on where in the network stack you want this you might need to go very low level. Anyway this is possible while still using a lot of what rama provides for you.

---

Tcp is stream based though. Usually within the process one does not see the actual packets... That said you can have low level control over the socket config and setup in Rama and you can also wrap the Tcp Stream (or make your own) to decide what is written/read/flushed etc... and when. I mean a lot of possibilities there. But that's about bytes, not "packets".

If you want to have control over the actual tcp "packets" you'll need to grab for something where you own the TCP stack, as long you do that in Rust or something that you can host from Rust (FFI) you can still choose to use Rama for everything else. As Rama is modular and allows you to use what you can and provide yourself what you want different. In the end stuff like an HTTP Connector just needs something that's a byte stream. It's for that same reason that with rama you can just as easily have a TCP client over a UNIX socket or even a bluetooth stack.... All is possible. Some just requires more work on your end than other things.

But then again, Rama is here to empower, just like Rust. So do not repeat what you do not have to, but do also not forget that writing code is part of the empowerment and fun.

---

If your full application is sync instead of async and you want to keep it like that you can still achieve that by spawning a thread for the rama-based client and run your own tokio runtime on that thread there.

---

If you can layout an exact plan of the things you want to do with it, as much as you can share of course, I can try to provide a bit more specific information.

TLDR: probably whatever you want to do is possible and Rama should be able to be part of your stack, even if just partially. Let's figure out together what exactly you want here. And how we can get there, if we are not there already.

[nastynaz]

Thank you for such a detailed write up and the offer to help.

After some thinking here’s my plan of attack:

• Bypass the kernel to get direct access to the network card using DPDK
• Instantiate a TCP stack using Rama
• Layer HTTP and TLS on top with Rama
• Send HTTP traffic without any async executor (not sure if Rama can do this)

Is it possible to do the TCP connection and TLS using fully sync, non-blocking code in Rama? One thing I want to avoid is tokio/async runtimes because it increases latency. Performance benchmarking shows that it costs around 7us latency on my machine to spawn a task on a tokio CT runtime.

Instead of an executor, everything will be driven by hot-polling the network sockets (extremely low latency at the expense of 100% cpu utilisation).

If I can get something working and useable I’m open to making it open-source.

[GlenDC]

You can easily bridge sync and async code yes. Well easily... it's not as easy as just running purely async code, but it isn't the end of the world either.

What you request is possible yes. And without spawning a tokio runtime. Perhaps it is not possible yet, but where you get stuck I can help you, might need some code changes.

Sometimes you might need to turn some of your sync code into it being async. For that there are some examples in rama already (e.g. look at how the websocket code (which is sync) is turned into async.

For the outer layer you will turn your connection future into something that you'll poll, with a combination of https://ramaproxy.org/docs/rama/futures/task/index.html and using the mio crate directly (which tokio is built upon).

It could be that you run into issues with it complaning that there is no tokio runtime. That might or might not be possible to avoid. If you are at such a point and you find now solution, let me know. We can also look that.

Worst worst case we can make sure that all code protocol code is possible to be run without tokio runtime at least. I would hope that what is there today we can make work for you with little work. I have my hopes. But it will require some back and forward (e.g. via discord or email) to make it happen.