René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Broken pipe (close_after=true) or endless retry loop (close_after=false) when exchanging classical messages","articleBody":"There is a race condition in the way classical channels are handled in Simulaqron that causes BrokenPipe errors.\r\n\r\nIt happens when node A sends two classical messages to node B in succession.\r\n\r\nSo, in node A we have:\r\nA1) sendClassical(\"B\", \"msg1\")\r\nA2) sendClassical(\"B\", \"msg2\")\r\n\r\nAnd in node B we have:\r\nB1) msg1 = recvClassical()\r\nB2) msg2 = recvClassical()\r\n\r\nWe have close_after set to the default value False in all calls.\r\n\r\nThe following sequence of events takes place:\r\n\r\nIn step A1, node A tries to connect to node B. This fails because node A has not yet created a listening socket. A keeps retrying.\r\n\r\nIn step B1, node B creates a listening socket \"s\" and waits for incoming connections. An incoming connection from A does indeed arrive, and node B accepts it which creates a connection socket \"conn\" (in addition to the listening socket).\r\n\r\nIn step A1, node A finally connects successfully and sends msg1.\r\n\r\nIn step A1, node A closes the connection to B.\r\n\r\nIn step A2, node A tries to connect to node B to send the second message msg2. This succeeds, because node B is still in step B1 and has not yet closed the listening socket for the first message.\r\n\r\nIn step B1, node B, receives msg1 from node A. After receiving msg1, node B closes connection socket conn (in function closeClassicalServer) but the listen socket is not explicitly closed. The listening socket which is still open still has a pending incoming connection from event 5 above.\r\n\r\nIn step B2, calls startClassicalServer again for the second incoming message. This creates a new listening socket \"s\" for the same port. This evidently has the side effect of causing the first listening socket which was never explicitly closed to be closed implicitly. Whatever, at this point node B gets a BrokenPipe error because the pending connection failed to complete.\r\n\r\nActually, the listening socket is probably closed when \"s\" goes out of scope when startClassicalServer exits the function. But still, the net result is the same. By this time, node A has already started sending msg2 and has already connected to this listening socket before it was closed. Thus, node A will get the BrokenPipe when the listening socket (which was intended for msg1 but which accidentally used for msg2 as well) gets closed.\r\n\r\nSimulaqron PythonLib should not be creating new listening sockets for every received message. There should only be one listening socket, and it should be used for the lifetime of the node.\r\n\r\nNote: if I set close_after to False in sendClassical and recvClassical, we run into another bug. We get stuck in an endless loop \"App Alice: Could not open classical channel to Eve, trying again..\" This is because PythonLib cannot handle having two simultaneous TCP connections to two different neighbor nodes (e.g. Eve having two connections, one to Alice and one to Bob) if close_after is False.\r\n\r\nIn general, the handling of sockets for classical messages is in need of some cleaning up.\r\n\r\nPS: All this opening and closing of sockets probably makes the protocols run quite slowly. We should make close_after=False the default and fix the code so that it can handle multiple simultaneous connections to multiple neighboring nodes.\r\n\r\n@AckslD If you would like me to give shot at fixing this myself, feel free to assign the issue to me. Or assign it to yourself if you prefer handling it yourself. If the former, it appears that there is no unit test library for pythonLib... is that correct?","author":{"url":"https://github.com/brunorijsman","@type":"Person","name":"brunorijsman"},"datePublished":"2019-12-06T14:00:44.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":2},"url":"https://github.com/58/CQC-Python/issues/58"}