On Thu, Nov 20, 2014 at 10:27 AM, Sebastian Lackner sebastian@fds-team.de wrote:
Based on a patch by Erich Hoover.
To avoid calculations on the client-side, the server sends the connect time as relative (negative) value. Needs tools/make_requests.
Hi, Sebastian. Thanks for taking care of this, but actually I'm thinking by doing this in a different way. I'm thinking about moving SO_CONNECT_TIME, SO_SNDBUF and SO_RECVBUF to the server with some new server message or the one Erich created for the WSAIoctl. By doing it this way we can fix not only this bug but also https://bugs.winehq.org/show_bug.cgi?id=8606 where we can store the pretended SO_SNDBUF value and return to the client when asked. Some other messages could also be done there like SO_EXCLUSIVEADDR, SO_DEBUG and others that require only memory to store/retrieve the value. This would also help for SO_ACCEPTCONN which is bugged in OSX due to a kernel problem. Not sure if my approach would be accepted anyway.
Best wishes, Bruno
On 20.11.2014 14:31, Bruno Jesus wrote:
On Thu, Nov 20, 2014 at 10:27 AM, Sebastian Lackner sebastian@fds-team.de wrote:
Based on a patch by Erich Hoover.
To avoid calculations on the client-side, the server sends the connect time as relative (negative) value. Needs tools/make_requests.
Hi, Sebastian. Thanks for taking care of this, but actually I'm thinking by doing this in a different way. I'm thinking about moving SO_CONNECT_TIME, SO_SNDBUF and SO_RECVBUF to the server with some new server message or the one Erich created for the WSAIoctl. By doing it this way we can fix not only this bug but also https://bugs.winehq.org/show_bug.cgi?id=8606 where we can store the pretended SO_SNDBUF value and return to the client when asked. Some other messages could also be done there like SO_EXCLUSIVEADDR, SO_DEBUG and others that require only memory to store/retrieve the value. This would also help for SO_ACCEPTCONN which is bugged in OSX due to a kernel problem. Not sure if my approach would be accepted anyway.
Best wishes, Bruno
Hi,
not sure if bug 8606 is still important, the weird behaviour is clearly based on ugly code in the game. If other programs probably do a lot of SO_SNDBUF, always using a wineserver calls might cause a significant slowdown. Besides that, based on your last report, the game servers don't even exist anymore. Doesn't that make it basically a WONTFIX?
Nevertheless, if you prefer a different solution I am also fine with that, at least if you have time to work on it in the near future. ;)
Regards, Sebastian
On 20.11.2014 14:43, Sebastian Lackner wrote:
On 20.11.2014 14:31, Bruno Jesus wrote:
On Thu, Nov 20, 2014 at 10:27 AM, Sebastian Lackner sebastian@fds-team.de wrote:
Based on a patch by Erich Hoover.
To avoid calculations on the client-side, the server sends the connect time as relative (negative) value. Needs tools/make_requests.
Hi, Sebastian. Thanks for taking care of this, but actually I'm thinking by doing this in a different way. I'm thinking about moving SO_CONNECT_TIME, SO_SNDBUF and SO_RECVBUF to the server with some new server message or the one Erich created for the WSAIoctl. By doing it this way we can fix not only this bug but also https://bugs.winehq.org/show_bug.cgi?id=8606 where we can store the pretended SO_SNDBUF value and return to the client when asked. Some other messages could also be done there like SO_EXCLUSIVEADDR, SO_DEBUG and others that require only memory to store/retrieve the value. This would also help for SO_ACCEPTCONN which is bugged in OSX due to a kernel problem. Not sure if my approach would be accepted anyway.
Best wishes, Bruno
Hi,
not sure if bug 8606 is still important, the weird behaviour is clearly based on ugly code in the game. If other programs probably do a lot of SO_SNDBUF, always using a wineserver calls might cause a significant slowdown. Besides that, based on your last report, the game servers don't even exist anymore. Doesn't that make it basically a WONTFIX?
Nevertheless, if you prefer a different solution I am also fine with that, at least if you have time to work on it in the near future. ;)
Regards, Sebastian
Just in addition to my previous msg - bug 8606 could also be easily fixed by just dividing the returned value by 2 if you're using a linux system. This "feature" of allocating twice the requested buffer is officially documented and unlikely to change in the near future: http://man7.org/linux/man-pages/man7/socket.7.html If we want to be completely on the save side we could also detect it at runtime on ws2_32 initialization.
On Thu, Nov 20, 2014 at 12:29 PM, Sebastian Lackner sebastian@fds-team.de wrote:
Just in addition to my previous msg - bug 8606 could also be easily fixed by just dividing the returned value by 2 if you're using a linux system. This "feature" of allocating twice the requested buffer is officially documented and unlikely to change in the near future: http://man7.org/linux/man-pages/man7/socket.7.html If we want to be completely on the save side we could also detect it at runtime on ws2_32 initialization.
That's why storing the value in the server and using min(memory_stored_value, getsockopt_value) would solve this issue. Dividing by 2 would require the introduction of #ifdef.
On Thu, Nov 20, 2014 at 11:43 AM, Sebastian Lackner sebastian@fds-team.de wrote:
Hi,
not sure if bug 8606 is still important, the weird behaviour is clearly based on ugly code in the game. If other programs probably do a lot of SO_SNDBUF, always using a wineserver calls might cause a significant slowdown. Besides that, based on your last report, the game servers don't even exist anymore. Doesn't that make it basically a WONTFIX?
Nevertheless, if you prefer a different solution I am also fine with that, at least if you have time to work on it in the near future. ;)
I agree that the server calls are bad but I've never seen any app that keeps calling these specific options many times since they are not supposed to change by themselves. It would make sense not to put FIONBIO in the server for example since it can be abused by applications that use it to poll for data instead of using select/async methods.
The bug is still there despite of the game code and that will also fix the test failures in BSD and Solaris where the SNDBUF and RECVBUF options are only hints to the kernel which usually ignores them completetly.
Regards, Sebastian
On 20.11.2014 15:30, Bruno Jesus wrote:
The bug is still there despite of the game code and that will also fix the test failures in BSD and Solaris where the SNDBUF and RECVBUF options are only hints to the kernel which usually ignores them completetly.
Isn't it the same on Windows? Quote from MSDN:
--- snip --- SO_RCVBUF and SO_SNDBUF When a Windows Sockets implementation supports the SO_RCVBUF and SO_SNDBUF options, an application can request different buffer sizes (larger or smaller). ->The call to setsockopt can succeed even when the implementation did not provide the whole amount requested.<- An application must call getsockopt with the same option to check the buffer size actually provided. --- snip ---
Seems like windows also doesn't give any guarantee that the value is used exactly as provided. Of course you can argue that some apps still might depend on that, but for me it sounds like at least the linux factor of 2 could be easily "solved" directly in usermode, without having new wineserver calls. Not sure about BSD or Salaris though.
On 20.11.2014 15:32, Bruno Jesus wrote:
That's why storing the value in the server and using min(memory_stored_value, getsockopt_value) would solve this issue. Dividing by 2 would require the introduction of #ifdef.
Setting a too small value would probably also get ignored or fail on Windows, so thats also not completely correct.
On Thu, Nov 20, 2014 at 12:40 PM, Sebastian Lackner sebastian@fds-team.de wrote:
On 20.11.2014 15:30, Bruno Jesus wrote:
The bug is still there despite of the game code and that will also fix the test failures in BSD and Solaris where the SNDBUF and RECVBUF options are only hints to the kernel which usually ignores them completetly.
Isn't it the same on Windows? Quote from MSDN:
--- snip --- SO_RCVBUF and SO_SNDBUF When a Windows Sockets implementation supports the SO_RCVBUF and SO_SNDBUF options, an application can request different buffer sizes (larger or smaller). ->The call to setsockopt can succeed even when the implementation did not provide the whole amount requested.<- An application must call getsockopt with the same option to check the buffer size actually provided. --- snip ---
Seems like windows also doesn't give any guarantee that the value is used exactly as provided. Of course you can argue that some apps still might depend on that, but for me it sounds like at least the linux factor of 2 could be easily "solved" directly in usermode, without having new wineserver calls. Not sure about BSD or Salaris though.
On 20.11.2014 15:32, Bruno Jesus wrote:
That's why storing the value in the server and using min(memory_stored_value, getsockopt_value) would solve this issue. Dividing by 2 would require the introduction of #ifdef.
Setting a too small value would probably also get ignored or fail on Windows, so thats also not completely correct.
I agree with everything you say but I would like the chance to try to do it the way I was thinking, if everything I do gets rejected we can always get back and commit Erich's patch and then find some other way to fix the other bugs. Maybe Alexandre or other project Jedi could give some ideas too.
-
Bruno Jesus -
Sebastian Lackner