View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001682 | GNUnet | transport service | public | 2011-05-31 18:17 | 2011-06-10 11:09 |
| Reporter | Christian Grothoff | Assigned To | Matthias Wachs | ||
| Priority | immediate | Severity | block | Reproducibility | random |
| Status | closed | Resolution | fixed | ||
| Summary | 0001682: gnunet-service-transport does not call GNUNET_SERVER_receive_done in a timely fashion | ||||
| Description | Oddly enough, the warning generated by util goes "away" after a while (resets to 0s), so either the service *did* eventually (after an undue time) call the receive_done function or this even causes a disconnect. I'm also not sure what the transport's business with messages of type 82 is to begin with... I can (often) reproduce this by running the perf_gnunet_service_fs_p2p_trust test case, which then ultimately fails because the last of the 3 downloads takes a loooong time (The testcase occasionally passes as this bug only appears at random). Also, P2P communication (if this is the cause for the failure) does not appear to be entirely down since some messages still get through, but since this is about 3 peers, those may be taking a different path. | ||||
| Additional Information | May 31 16:11:03 transport-27601 WARNING Processing code for message of type 82 did not call GNUNET_SERVER_receive_done after 18066ms May 31 16:11:04 transport-27601 WARNING Processing code for message of type 82 did not call GNUNET_SERVER_receive_done after 19070ms May 31 16:11:05 transport-27601 WARNING Processing code for message of type 82 did not call GNUNET_SERVER_receive_done after 20074ms May 31 16:11:12 transport-27556 WARNING Processing code for message of type 82 did not call GNUNET_SERVER_receive_done after 1001ms May 31 16:11:13 transport-27556 WARNING Processing code for message of type 82 did not call GNUNET_SERVER_receive_done after 2006ms | ||||
| Tags | No tags attached. | ||||
|
|
The TCP plugin passes payload directly to the transport service, which then can return a delay (!) for reading (push back) if the other side is sending data faster than we'd like. The TCP plugin then uses the 'delayed_done' function to perform the call to 'GNUNET_SERVER_receive_done' with the specified delay. This is totally consistent with the warning we get here. The only question now is why the *sender* (the other peer) gets so close (and/or beyond) the agreed-upon quota to trigger this push back in the first place. |
|
|
Added new API call to disable the warning IF we delay intentionally (as done here by TCP). Real issue is that somehow the quota is reduced to 1kb/s for the testcase, causing excessive delays. But that's a different bug. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-05-31 18:17 | Christian Grothoff | New Issue | |
| 2011-05-31 18:17 | Christian Grothoff | Status | new => assigned |
| 2011-05-31 18:17 | Christian Grothoff | Assigned To | => Matthias Wachs |
| 2011-06-06 13:54 | Christian Grothoff | Note Added: 0004340 | |
| 2011-06-06 13:54 | Christian Grothoff | Note Added: 0004341 | |
| 2011-06-06 13:54 | Christian Grothoff | Status | assigned => resolved |
| 2011-06-06 13:54 | Christian Grothoff | Resolution | open => fixed |
| 2011-06-10 11:09 | Christian Grothoff | Status | resolved => closed |
