Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Users Search
Help Dashboard Sign In Sign Up
Q&A Code Reviews Meta
Q&A
Posts Tags Edits
Ask Question

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Comments on Read all data from TCP stream in Rust

Post

Read all data from TCP stream in Rust

+5
−1

I'd like to write a TCP client in Rust that can receive the entire message sent by a server, but I have no information about the length of a message.

I'm aware that TCP doesn't preserve message boundaries.

Still, what's the best I can do to read the entire message from the TcpStream?

In the scenario the client should work, there's no protocol for the messages sent from server to client: The client doesn't know beforehand how many bytes are in a message and the message doesn't have a header (as in HTTP) that would contain the message length. There's no special delimiter that marks the end of a message.

Also, the server might keep the TCP connection open after sending a message, meaning I can not rely on every message being completed with a server FIN.

I'd like to do this using Rust's standard library only, no other dependencies.

rust tcp
posted over 1 year ago
1y ago
user card
Matthias Braun‭
93 reputation 4 1 14 11
History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

There's nothing you can do. It's impossible. Setting a timeout doesn't guarantee the received data i... (5 comments)
There's nothing you can do. It's impossible. Setting a timeout doesn't guarantee the received data i...
__blackjack__‭ wrote over 1 year ago
copy link

There's nothing you can do. It's impossible. Setting a timeout doesn't guarantee the received data is a complete message.

Matthias Braun‭ wrote over 1 year ago
copy link

The code in the answer I've added (the one setting the timeout) worked for getting the HTML/CSS/JS of a web server and for a custom TCP server that used no protocol. I'm sure there are situations where the 200 ms timeout is too low, so you're right that there's no guarantee to get the whole message. But the code shows that there's something you can do.

__blackjack__‭ wrote over 1 year ago
copy link

Yes of course, you can write broken code. And put it on the internet, as an ”answer”, so others can copy that broken code. I think it's a disservice and should not have a place on a Q&A site that aims to curate good, correct, answers. This one isn't even correct. The correct answer to this question isn't code, but that it's impossible.

Matthias Braun‭ wrote over 1 year ago
copy link

Can you provide an example server where the code doesn't work? This way, we could improve it or show how it fails.

__blackjack__‭ wrote over 1 year ago
copy link

It's not an example server but network infrastructure that may delay traffic for any number of reasons longer than any arbitrary timeout you may define to ”detect” the end of the message.