View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003580 | GNUnet | transport service | public | 2014-12-16 02:50 | 2024-05-03 13:58 |
| Reporter | cy1 | Assigned To | Matthias Wachs | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | no change required | ||
| Product Version | Git master | ||||
| Target Version | 0.11.0pre66 | Fixed in Version | 0.11.0pre66 | ||
| Summary | 0003580: UDP transport could maybe be discarding data? | ||||
| Description | Normally when reading from a network to messages, I will append the bytes that come in into a larger buffer, and then attempt to find messages within that buffer, finally moving the tail end of the buffer to the beginning of the buffer for more data to come in. Is that too paranoid a strategy? The smallest limit we would ever find on UDP packets is 576 bytes minus headers, so 548 bytes. Are all messages sent by GNUnet guaranteed to be less than 548 bytes? If there's a 1024 byte message for instance, it would be split into 2 packets, 548 and 476 respectively, though the message after that could be appended to the 476 up to 548. On receiving the first packet, unix_plugin_do_read will discard it since 1024 (csize) > 548 (ret). In this hypothetical situation the next packet to arrive would be the 476 byte one, which is the tail end of the previous message, and the msg->header structure will just be garbled data that happened to be at the front there, which will probably discard the second packet too, or allow that packet with garbage data if the bytes of the csize happen to be less than 476, thus injecting garbage data into the transport system. Other even worse possibilities might occur. Because the unix_plugin_do_read searches the packet for multiple messages, it could end up injecting multiple garbage messages into the transport system. And if the size of the messages do not perfectly align with 548, then you could get say, 3 messages, and the 4th could be divided between that packet and the next, resulting in all the messages in the next packet being lost, and that misalignment could even continue to the packet after that. If all messages are 54 bytes for example, the first 10 will arrive perfectly, and the rest of the messages until the modulo wrapped around would be garbage or lost. Is that unreasonable to assume? Does GNUnet make carefully sure that when it buffer messages to send, it does not go over the 548 byte limit before flushing that buffer? Sorry if I really don't understand this very well, 440,468 lines of code is a bit daunting to figure out on my own. I'm trying to figure out where to put message handling hooks, but can't quite see how messages assure that they don't end up divided between packets. | ||||
| Tags | No tags attached. | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-12-16 02:50 | cy1 | New Issue | |
| 2014-12-16 02:50 | cy1 | Status | new => assigned |
| 2014-12-16 02:50 | cy1 | Assigned To | => Matthias Wachs |
| 2014-12-16 03:33 | cy1 | Note Added: 0008694 | |
| 2014-12-16 03:33 | cy1 | Status | assigned => resolved |
| 2014-12-16 03:33 | cy1 | Resolution | open => no change required |
| 2015-03-21 00:34 | Christian Grothoff | Fixed in Version | => 0.11.0pre66 |
| 2015-03-21 00:34 | Christian Grothoff | Target Version | => 0.11.0pre66 |
| 2018-06-07 00:25 | Christian Grothoff | Status | resolved => closed |
| 2024-05-03 13:58 | Christian Grothoff | Category | UDP transport => transport service |
