bitshares / bitshares/bitshares-core
[FC] Writing to a tcp_socket which has EOF'd may hang forever
- Dominant language
- C++
- Stars
- 1.2k
- Forks
- 660
- Avg merge
- 8h 17m
- Merged PRs (30d)
- 26
Description
_From @nathanhourt on April 5, 2016 21:48_
Reporting here, as cryptonomex/fc does not track issues and I assume no one cares about bytemaster/fc anymore.
Calling `write` on a `fc::tcp_socket` which has reached EOF on a previous `read` may work, or it may hang forever (I find that it will always hang forever if enough bytes are written or write is called multiple times). Writing to a TCP socket when the remote end has shutdown writes is explicitly legal under TCP semantics, so this should either work or throw.
Note that it is apparently impossible to handle this gracefully as FC's normal timeout mechanisms fail in this instance as well. I attempted something similar to the following:
``` c++
if (haveReadEof) {
fc::async(socket.write(...)).wait(fc::milliseconds(100));
} else {
socket.write(...);
}
```
This also did not work, as the call to `wait(fc::milliseconds(100))` hangs forever when `socket.write` hangs forever, instead of throwing `fc::timeout_exception` as it should. My workaround is simply to throw if an EOF has been read, without trying to write.
_Copied from original issue: cryptonomex/graphene#646_
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by tracing the fc::tcp_socket write path and the fc::async wait behavior described in the report. Reproduce the case where a socket has observed EOF, then verify that writes either complete or throw and that the timeout returns instead of hanging.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100