[Bug 10648] New: Async WSASend does not send all bytes.
http://bugs.winehq.org/show_bug.cgi?id=10648 Summary: Async WSASend does not send all bytes. Product: Wine Version: 0.9.5. Platform: Other OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: test AssignedTo: wine-bugs(a)winehq.org ReportedBy: marius(a)scimore.com On Server sending 1500 bytes with non-blocked WSASend and 2 WSABUFFERS will transfer only 1452 bytes. On client WSARecv called again will be blocked and does not receive the the remaining bytes. The completion port receives event on transfered 1452 bytes, and there is no more followed events on transfered the last 8 bytes. OS: Ubuntu 7.10 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10648 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|testcases |-unknown --- Comment #1 from Austin English <austinenglish(a)gmail.com> 2008-04-28 16:29:05 --- Can you upload a small test case (source and binary) showing this problem? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10648 --- Comment #2 from Andrew Nguyen <arethusa26(a)gmail.com> 2008-11-02 20:44:29 --- This bug seems to be abandoned. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10648 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |ABANDONED --- Comment #3 from Austin English <austinenglish(a)gmail.com> 2008-11-02 21:47:58 --- Abandoned. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10648 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #4 from Austin English <austinenglish(a)gmail.com> 2008-11-02 21:48:04 --- Closing. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=10648 Jinoh Kang <jinoh.kang.kr(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jinoh.kang.kr(a)gmail.com --- Comment #5 from Jinoh Kang <jinoh.kang.kr(a)gmail.com> --- Requesting to reopen the ticket. The gRPC library relies on the all-or-none behaviour of nonblocking send() on Winsock. All applications relying on gRPC thus fails to transmit RPC packets properly. It's possible to patch gRPC instead [1] so that it properly handles partial writes, but it is not always feasible in proprietary software applications. Possible directions for the fix include: - In sock_send(), test if it's possible to actually send the full stream data before calling send(). - On partial write, queue up the rest of the buffer and report success. [1] https://github.com/grpc/grpc/pull/28432/files -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=10648 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|ABANDONED |--- Ever confirmed|0 |1 CC| |z.figura12(a)gmail.com Status|CLOSED |REOPENED Component|-unknown |winsock Summary|Async WSASend does not send |gRPC library fails to send |all bytes. |RPC packets correctly | |(nonblocking send() should | |not perform partial writes) --- Comment #6 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Jinoh Kang from comment #5)
Requesting to reopen the ticket.
The gRPC library relies on the all-or-none behaviour of nonblocking send() on Winsock. All applications relying on gRPC thus fails to transmit RPC packets properly.
It's possible to patch gRPC instead [1] so that it properly handles partial writes, but it is not always feasible in proprietary software applications.
I've reopened, but fixing applications is preferable if at all possible. It's not clear that any other applications actually care about short write behaviour.
Possible directions for the fix include:
- In sock_send(), test if it's possible to actually send the full stream data before calling send().
How?
- On partial write, queue up the rest of the buffer and report success.
This seems to me like the only option feasible right now, although it's obviously far from ideal. Of course, we could also try to introduce an extra socket option or flag into the kernel. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=10648 --- Comment #7 from Jinoh Kang <jinoh.kang.kr(a)gmail.com> --- (In reply to Zebediah Figura from comment #6)
(In reply to Jinoh Kang from comment #5)
Requesting to reopen the ticket.
The gRPC library relies on the all-or-none behaviour of nonblocking send() on Winsock. All applications relying on gRPC thus fails to transmit RPC packets properly.
It's possible to patch gRPC instead [1] so that it properly handles partial writes, but it is not always feasible in proprietary software applications.
I've reopened, but fixing applications is preferable if at all possible. It's not clear that any other applications actually care about short write behaviour.
Possible directions for the fix include:
- In sock_send(), test if it's possible to actually send the full stream data before calling send().
How?
Heuristics. Actually it would require *both* remedies in order for the final solution to be plausible at all.
- On partial write, queue up the rest of the buffer and report success.
This seems to me like the only option feasible right now, although it's obviously far from ideal.
Combined with heuristics above, I think this won't happen that much frequently in practice.
Of course, we could also try to introduce an extra socket option or flag into the kernel.
Linux maybe, but Darwin... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=10648 --- Comment #8 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Jinoh Kang from comment #7)
(In reply to Zebediah Figura from comment #6)
(In reply to Jinoh Kang from comment #5)
- In sock_send(), test if it's possible to actually send the full stream data before calling send().
How?
Heuristics. Actually it would require *both* remedies in order for the final solution to be plausible at all.
What heuristics do you have in mind, exactly? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=10648 --- Comment #9 from Jinoh Kang <jinoh.kang.kr(a)gmail.com> --- A recently posted MR, https://gitlab.winehq.org/wine/wine/-/merge_requests/6490, should fix this bug. The MR is for "JOY OF PROGRAMMING - Software Engineering Simulator." -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=10648 --- Comment #10 from Jinoh Kang <jinoh.kang.kr(a)gmail.com> --- This should be fixed in 535c8a84c1ec4391786d8be6f87d683e20223b12. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=10648 Paul Gofman <pgofman(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |535c8a84c1ec4391786d8be6f87 | |d683e20223b12 CC| |pgofman(a)codeweavers.com Resolution|--- |FIXED Status|REOPENED |RESOLVED --- Comment #11 from Paul Gofman <pgofman(a)codeweavers.com> --- Marking resolved. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=10648 Paul Gofman <pgofman(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1|535c8a84c1ec4391786d8be6f87 | |d683e20223b12 | Fixed by SHA1| |535c8a84c1ec4391786d8be6f87 | |d683e20223b12 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=10648 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #12 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 9.18. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla