New issue
Advanced search Search tips

Issue 638310 link

Starred by 1 user
Status: WontFix
Owner: ----
Closed: Aug 2016
Cc:
mef@chromium.org
ios-bugs@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: iOS
Pri: 2
Type: Feature



Sign in to add a comment

Add |end_of_stream| flag to on_read_completed() C callback

Project Member Reported by kapishnikov@chromium.org, Aug 16 2016 
Cronet Java API passes |endOfStream| flag to the onReadCompleted() bidirectional stream callback. This makes it very easy for the client to determine that the end of stream has been reached and onSucceeded() callback will be fired shortly (if write is completed too):

https://cs.chromium.org/chromium/src/components/cronet/android/api/src/org/chromium/net/BidirectionalStream.java?sq=package:chromium&l=254

public abstract void onReadCompleted(BidirectionalStream stream,
                                     UrlResponseInfo info,
                                     ByteBuffer buffer,
                                     boolean endOfStream);

On iOS, in order to detect the end of stream and trigger the on_succeded() callback, the client needs to call read() until 0 bytes are received. This makes the client logic more complicated. It is also not obvious that on_succeded() may not be called even if all data were read:

https://cs.chromium.org/chromium/src/components/cronet/ios/cronet_c_for_grpc.h?sq=package:chromium&l=77

void (*on_read_completed)(cronet_bidirectional_stream* stream,
                          char* data,
                          int bytes_read);

We need to add |end_of_stream| flag to the C API callback and make it consistent with the Java API.

Comment 1 by kapishnikov@chromium.org, Aug 16 2016

Status: WontFix (was: Untriaged)
I looked at the Java implementation and I was actually wrong regarding the behaviour of the API. It is still required calling read() until 0-bytes are received. The |endOfStream| flag is set to 'true' only if the number of received bytes is 0. Thus, the functionally of Java API matches the C/iOS one, i.e the C client can simply call:
bool end_of_stream = (bytes_read == 0); to get the value of the flag.

Depending on the protocol and the server logic, the client may not know that the last received packet is the final one. E.g., the EOS packet can arrive separately after the last data have been sent. Therefore, in general case, the client needs to read() the data continuously to make sure that the EOS has been reached and there are no unexpected data. Both Java & C APIs are implemented with this assumption.

I am closing this bug as infeasible since:
1) It is technically difficult to implement. It will require implementing additional callbacks in protocols that would signal EOS separate from the data reads + plumbing them to the Cronet level.
2) It will only address the case when the client knows the exact number of expected bytes and there is guarantee that the server won't send more data than expected.
►

Sign in to add a comment