So I’m getting a pretty good grip on Rust lately, I think. A lot of the stuff I made formerly in C/C++ were usually servers or clients for a type of network. When I was a novice in this, I started out with naive attempts using Qt’s QDataStreams and parsing binary data from a QTcpSocket, while hooking up events with it’s signals/slots feature. Eventually, I realised the relevence of asynchronicity when sending data and, also yearning for a more flexible license and less DLL/dependency-heavy, switched to Boost’s ASIO library, buffering my data with strands and worker threads, etc.
Now that I’m on Rust, I’m seeing the top contenders for similar functionality as QtNetwork/Boost.ASIO would be Tokio and MIO. MIO flat out states it is low-level and refers me to Tokio for more easier functionality. So I go to look at Tokio, which seems to have a pretty straightforward example on its front page. However, the tutorial says tokio_proto is recommended for newbies. I looked over how codecs and protocols are coded, and while it seems… understandable… I’m rather concerned about how this codec/protocol model sends and receives data. It seems to send/receive all data in one structured format (ie. all data must be a line of UTF8 text) as opposed to, perhaps, an initial ‘hello’-type message that contains metadata and THEN the string messages going back and forth.
I think a simple example of what would help me understand it better is… how would one go about making a minimalistic Hotline client? The protocol spec (found here) basically starts with the client sending the bytes ‘T’, ‘R’, ‘T’, ‘P’, 0, 1, 0, 2 as a greeting, with the server replying with ‘T’, ‘R’, ‘T’, ‘P’ if successful, and THEN it goes into an event loop where the data is structured. How would tokio_proto go about doing that as well as heeding the greeting data? Because, as you can see, the data isn’t always sent in a fixed format.
I suppose, perhaps, instead, it would be better to find out how Tokio can simply send and receive buffered data asynchronously instead of all the codec/protocol gobbledeegook.