Support for streaming services

[raamb]

As we enable support for streaming services we need to decide how we will enable interaction with such services. Since the client generates stubs dynamically it needs to identify which service uses client side streaming, server side streaming or bi-directional streaming and accordingly capture inputs and render outputs.

cc @astroseger @arturgontijo @ferrouswheel @vforvalerio87 @vsbogd

[ferrouswheel]

Happy to hear how others think it might work, but for me it's not clear how we can do this in a generic way for calling from the CLI without potential deadlocks, since the communication pattern isn't defined anywhere.

Streaming should probably be an advanced topic which service authors need to define the protocol for, and only supported when there is client code to handle the communication (i.e. the custom dapp UI components or the SDK).

Edit: as an example, say I want to send a large image via a stream, so it gets split up into 4096 byte chunks, and the first message contains the total file size so the server knows how many chunks to receive before reconstructing and processing the image. A new image is then return to the caller using a similar mechanism.

In this scenario the number of streamed messages is encoded inside the protobuf messages, and is dependent on the size of the images. Because this number is internal to the messages, it'd be hard for us to introspect anything about it that could be useful to the CLI.

[raamb]

Happy to hear how others think it might work, but for me it's not clear how we can do this in a generic way for calling from the CLI without potential deadlocks, since the communication pattern isn't defined anywhere.

Yes, completely agree. This is a non-trivial problem and we need to have a way to deal with it i.e. we display an appropriate message where we cannot support and indicate options for the developer to try instead

[vsbogd]

We have discussed it with @astroseger today:

• if client uses SDK then it can implement protocol which is described by publisher in protobuf comments and there is no protocol specification problem;
• for snet-cli we can implement it asking client to provide number of messages to sent to the service and showing messages received one by one, after all snet-cli is low-level tool to make fast checks;
• it is a real problem for services which calls other services for this use case we need to find a way to describe API formally.

One of the ways to describe it formally would be a introducing:

message Chunk {
  bytes data = 1;
}

which can be used by service publisher to send big amount of data. If request message contains fields with Chunk type then SDK or snet-cli will break this bytes to the chunks and form stream of messages. Like:

message Request {
  string mime = 1;
  Chunk video = 2;
}

will be converted to the stream of Requests each contains only chunk of video field data.

[astroseger]

So in any case we need to have some predefined scenarios. Two the most simplest one

• stream-as-request, simple one time request-response scenario, but client sends request as a stream and wait response
• stream-as-request, simple one time request-response scenario, but client receives response as a stream.
• other more complicated scenarios could be defined later if needed...

We only need to have a way for the client to know which scenario he need to follow. For example as @vsbogd has proposed it can be simple "inheritance" of predefined (by us) types...

[ferrouswheel]

If we do use predefined types let's follow the way many grpc authors do it and have a one_of stanza that splits every message into being a header or Chunk, to avoid sending extra metadata e.g. mimetype with every streamed message.

On Wed, 10 Apr 2019, 10:40 PM Sergey Rodionov, notifications@github.com wrote:

So in any case we need to have some predefined scenarios. Two the most simplest one

• stream-as-request, simple one time request-response scenario, but client sends request as a stream and wait response
• stream-as-request, simple one time request-response scenario, but client receives response as a stream.
• other more complicated scenarios could be defined later if needed...

We only need to way for the client to know which scenario he need to follow. For example as @vsbogd https://github.com/vsbogd has proposed it can be simple "inheritance" of predefined (by us) types...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/singnet/snet-cli/issues/245#issuecomment-481638262, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHWBxg6t2rejv6g3Giuyj8Hci5hA3GVks5vfb-SgaJpZM4cmEHX .