{"action":"created","issue":{"url":"https://api.github.com/repos/Bitmessage/PyBitmessage/issues/776","labels_url":"https://api.github.com/repos/Bitmessage/PyBitmessage/issues/776/labels{/name}","comments_url":"https://api.github.com/repos/Bitmessage/PyBitmessage/issues/776/comments","events_url":"https://api.github.com/repos/Bitmessage/PyBitmessage/issues/776/events","html_url":"https://github.com/Bitmessage/PyBitmessage/issues/776","id":56815057,"number":776,"title":"Stream state in receiveDataThread may become corrupted","user":{"login":"Kagami","id":533383,"avatar_url":"https://avatars.githubusercontent.com/u/533383?v=3","gravatar_id":"","url":"https://api.github.com/users/Kagami","html_url":"https://github.com/Kagami","followers_url":"https://api.github.com/users/Kagami/followers","following_url":"https://api.github.com/users/Kagami/following{/other_user}","gists_url":"https://api.github.com/users/Kagami/gists{/gist_id}","starred_url":"https://api.github.com/users/Kagami/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Kagami/subscriptions","organizations_url":"https://api.github.com/users/Kagami/orgs","repos_url":"https://api.github.com/users/Kagami/repos","events_url":"https://api.github.com/users/Kagami/events{/privacy}","received_events_url":"https://api.github.com/users/Kagami/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/Bitmessage/PyBitmessage/labels/enhancement","name":"enhancement","color":"84b6eb"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-02-06T14:03:33Z","updated_at":"2015-02-06T19:34:54Z","closed_at":null,"body":"Hi. As I understand this lines of code: https://github.com/Bitmessage/PyBitmessage/blob/master/src/class_receiveDataThread.py#L134-L139\r\nIf `paylodLength` specified in message header is too big we cut as many bytes from data buffer as we can and go to the next cycle.\r\nThe problem is that we don't check whether we've fetched all message already (though this is right decision because sender may specify up to 4G bytes in this field), we just cut it and try to assemble new message.\r\nSo the stream may get the following state:\r\n\r\nBuffer at first iteration:\r\n```\r\n[[length] [.........................big payload...................]] [[length2] [payload2]]\r\n                                  ^ cut here\r\n```\r\n\r\nBuffer at second iteration:\r\n```\r\n[.......big payload...................]] [[length2] [payload2]]\r\n```\r\n\r\nAt the second iteration we try to match message fields (magic, command, length, etc.) from the begging of the data buffer. And we will constantly fail now because buffer doesn't start with a message.\r\n\r\nI think we should try to match magic field as mentioned in spec, shouldn't we?"},"comment":{"url":"https://api.github.com/repos/Bitmessage/PyBitmessage/issues/comments/73298576","html_url":"https://github.com/Bitmessage/PyBitmessage/issues/776#issuecomment-73298576","issue_url":"https://api.github.com/repos/Bitmessage/PyBitmessage/issues/776","id":73298576,"user":{"login":"Kagami","id":533383,"avatar_url":"https://avatars.githubusercontent.com/u/533383?v=3","gravatar_id":"","url":"https://api.github.com/users/Kagami","html_url":"https://github.com/Kagami","followers_url":"https://api.github.com/users/Kagami/followers","following_url":"https://api.github.com/users/Kagami/following{/other_user}","gists_url":"https://api.github.com/users/Kagami/gists{/gist_id}","starred_url":"https://api.github.com/users/Kagami/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Kagami/subscriptions","organizations_url":"https://api.github.com/users/Kagami/orgs","repos_url":"https://api.github.com/users/Kagami/repos","events_url":"https://api.github.com/users/Kagami/events{/privacy}","received_events_url":"https://api.github.com/users/Kagami/received_events","type":"User","site_admin":false},"created_at":"2015-02-06T19:34:54Z","updated_at":"2015-02-06T19:34:54Z","body":">once the remote node stops sending whatever it is sending, then, after that, there is a high probability that the next data to arrive would start with the magic bytes\r\n\r\nYea, seems like in normal circumstances stream should normalize after some time. Anyway, normal nodes shouldn't send messages of that size, it may be also other unfixable implementation errors. This issue is rather \"good to have\" and enhancement than some serious bug.\r\nThe only use case which comes to my mind is to improve communication between partially compatible Bitmessage implementations (e.g. between node which implements protocol v3 and node which implements some protocol vX with bigger messages).\r\n\r\n>Although seeing as there are probably about half a million ways to misbehave and waste bandwidth\r\n\r\nI think \"error counter\" may be used to address this issue. If node does a lot of strange things, we may disconnect and ban it for some time."}}