[Bug 31438] [EA Origin]Unable to download game since the new version

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=31438

--- Comment #121 from Alessandro Pignotti <alexpigna.dev at gmail.com> ---
I agree the docs says that TcpSockets should always be buffered, but this does
not seem to be true. They definitely are buffered by default, but for HTTP
connection the mode is changed in
QHttpNetworkConnectionChannel::ensureConnection. You can see that when the
connection is not SSL based it will pass the QIODevice::Unbuffered flag to the
connectToHost call.

(In reply to Heiko from comment #119)
> "
> // Short circuit for getChar()
>     if (maxSize == 1) {
>         int chint;
>         while ((chint = d->buffer.getChar()) != -1) {
> ",
> i.e. buffer usage even in the 1 byte case, so that wine doesn't get battered
> directly.

That only works if the device is actually buffered, if the buffer is empty
getChar will return -1 and the normal code path will be taken. You can see that
the buffer is filled later in QIODevice::read, but only if the openMode is not
Unbuffered.

> 
> Also, when debugging wine's winsock it didn't look like there were 1 byte
> request from the beginning. Though there were 1-byte requests later on, but
> that didn't look like that was on the HTTP header anyway and to be
> application related. Then, something's really screwed.  And what makes me
> also wonder is that somehow there's directly a WS_recv after the WS_send.
I've actually been able to see those 1 byte request in the winsock trace.

> 
> And if Qt were to actually read one byte from the WSASocket, other
> Qt-applications would fail that miserably as well, which they don't.
Well, I agree on this, but maybe Origin downloads maybe small chunks using
HTTP. This is just speculation though.
> 
> But it seems, that wine somehow does send too many WM_USER messages in
> response to the armed WSAAsyncSelect events. It should only provide one
> message until being rearmed afaik.

The messages we all see are not (all) caused by the WSAAsyncSelect notification
mechanisms, but by WSARecv message sending a new notification if there is more
data available, citing MSDN on the WSAAsyncSelect article. WSARecv is a
reeanbling routine.

"For FD_READ, FD_OOB, and FD_ACCEPT events, message posting is level-triggered.
This means that if the reenabling routine is called and the relevant condition
is still met after the call, a WSAAsyncSelect message is posted to the
application. This allows an application to be event-driven and not be concerned
with the amount of data that arrives at any one time. Consider the following
sequence:"

-- 
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.