5g-era / era-5g-client Goto Github PK

Currently, only one results callback is specified for the client library, and the integrator must handle multiple results from the network application. We should alter the interface to enable multiple callbacks, one per each type of result.

When catching H264EncoderError the client is disconnected from the server. This should be handled better, maybe restart the encoder?

In the example clients, the TEST_VIDEO_FILE is checked even when the FROM_SOURCE variable is True, which means that no video file is needed.

For transferring image-based results (especially in the case of higher resolution), the client should be able to request a GStreamer connection from Network Application to the client.

• Heartbeat between the client (robot) and network application
• Heartbeat network application and middleware
• Recovery strategy when connection between the robot and network application is lost

In the client.py there is a function "gateway_get_plan" that returns the id of the generated plan by middleware.

Could we also have another function that will return the whole plan as a dictionary? I would like it for my own parsers to get other data.

Many thanks!

Not all clients want to send data; some only care about results obtained from data from another client. The client should specify during the handshake phase that it wants to act as a publisher or subscriber, or both at the same time. To correctly map multiple clients, a common id must be specified by all clients who want to receive the results.

• GetState() -> state - return the current state (model) of the service
• SetState(state) - replace the current state of the service
• SaveState(id) - save the current state of the service to persistent storage
• LoadState(id) - retrieve the state of the service from persistent storage

HTTP transport is the default option for transferring data to the network application. A special parameter has to be set for WebSocket transport usage. However, the WebSocket transfer is faster than HTTP transport, especially for extensive data, such as images. We should change that and use the WebSocket by default.

The client should allow adding metadata to HTTP and WebSocket /image streams to optionally allow multiple image streams at a time.

Current signature of the method: send_image_http(self, frame: np.ndarray, timestamp: Optional[str] = None, batch_size: int = 1)
New signature: send_image_http(self, frame: np.ndarray, topic_id: Optional[str] = None, timestamp: Optional[str] = None, batch_size: int = 1)