Anonymous | Login | 2024-11-21 11:57 CET |
Main | My View | View Issues | Change Log | Roadmap | My Account |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0000061 | Soldat Dedicated Server | Admin-Client Protocol | public | 2011-09-21 17:08 | 2015-04-13 02:42 | ||||
Reporter | Quantifier | ||||||||
Assigned To | Shoozza | ||||||||
Priority | urgent | Severity | major | Reproducibility | random | ||||
Status | resolved | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | 2.7.0 | ||||||||
Target Version | Fixed in Version | 2.7.9 | |||||||
Summary | 0000061: Ambiguous admin protocol with REFRESH packet | ||||||||
Description | When admin client sends raw command REFRESHX, the server responds with line "REFRESHX\r\n", then 1992 octets of binary data. Sometimes, the binary data does not immediately follow, when by race condition server sends a different line. Actual data is then misaligned with what admin client has read. Trailer of the packet is then read in line mode, possibly causing client to not recognize next "REFRESHX\r\n" line. | ||||||||
Tags | No tags attached. | ||||||||
John | |||||||||
Attached Files | |||||||||
Notes | |
(0001279) Shoozza (administrator) 2011-12-21 10:41 |
Is there an easy way to reproduce this bug? |
(0001282) Quantifier (reporter) 2011-12-21 11:10 |
Unfortunately no, you only can create favorable conditions. Which are server script which produces lots of output, and modified admin client that request REFRESH a dozen or so times a second. Then just wait. |
(0002392) chrisgbk (reporter) 2015-04-11 06:27 |
Not sure if this has ever been fixed yet. This is caused by the server having writeln('REFRESHX'), then a separate line to write the rest of the REFRESHX packet. Under load, due to multithreading, a chat message, script message, or any other notification can slip in between the two calls, resulting in the end of the REFRESHX packet being treated as text. And probably containing a NUL byte that breaks everything. The easy fix is to move the 'REFRESHX' string, with appropriate line endings, into the start of the REFRESHX record itself, so when the record gets sent it happens all at once (or alternatively create a temporary buffer, write the string to that buffer, copy the record in at the end of the string, then send the buffer at once) |
(0002393) Shoozza (administrator) 2015-04-13 02:42 |
Thanks ChrisGBK. It should be fixed now ;) |
Issue History | |||
Date Modified | Username | Field | Change |
2011-09-21 17:08 | Quantifier | New Issue | |
2011-12-21 10:41 | Shoozza | Note Added: 0001279 | |
2011-12-21 10:41 | Shoozza | Status | new => feedback |
2011-12-21 11:10 | Quantifier | Note Added: 0001282 | |
2011-12-21 11:10 | Quantifier | Status | feedback => new |
2012-02-16 12:22 | Shoozza | Status | new => acknowledged |
2012-12-01 22:44 | Falcon | Category | General => Admin-Client Protocol |
2015-04-11 06:27 | chrisgbk | Note Added: 0002392 | |
2015-04-13 02:42 | Shoozza | Note Added: 0002393 | |
2015-04-13 02:42 | Shoozza | Status | acknowledged => resolved |
2015-04-13 02:42 | Shoozza | Fixed in Version | => 2.7.9 |
2015-04-13 02:42 | Shoozza | Resolution | open => fixed |
2015-04-13 02:42 | Shoozza | Assigned To | => Shoozza |
Copyright © 2000 - 2024 MantisBT Team |