Can quic be used instead of http?

[sixhj]

🚀 Feature Request

Relevant Package [REQUIRED]

This feature request is for... There is a large amount of http in the project. It is recommended to switch to quic to improve performance. ### Description [**REQUIRED**] A clear and concise description of the problem or missing capability... A lot of http is used in the project, such as core-command, core-data, and core-metadata. Each http request requires a three-way handshake. QUIC has been optimized to improve the efficiency of the request. ### Describe the solution you'd like If you have a solution in mind, please describe it. The client I want to use when writing app-service is QUIC, so that the request\response time can be reduced as much as possible. ### Describe alternatives you've considered Have you considered any alternative solutions or workarounds? I have considered gRPC, but it seems a bit heavy to use on the edge of the Internet of Things. I have considered Coap, but it is too simple and does not meet the security requirements.

[cloudxxx8]

@sixhj please fill out the issue template with more information, such as performance comparison and further pros / cons. thanks

[bnevis-i]

The client I want to use when writing app-service is QUIC, so that the request\response time can be reduced as much as possible.

@sixhj, do you have a particular latency or performance target in mind that EdgeX needs to meet? Have you confirmed that switching to QUIC enables EdgeX to meet that target when today it does not?

[sixhj]

The client I want to use when writing app-service is QUIC, so that the request\response time can be reduced as much as possible.

@sixhj, do you have a particular latency or performance target in mind that EdgeX needs to meet? Have you confirmed that switching to QUIC enables EdgeX to meet that target when today it does not?

The timely delivery of instructions to devices is crucial when controlling them in batches. With over 100 terminal devices, any significant delay would jeopardize the prompt execution and orderly coordination of actions.

[lenny-goodell]

@sixhj , EdgeX uses the MessageBus to push event data from Device Services to App Services. REST is no longer used for this. Sending commands from App Service to Device services can now also be done via the MessageBus instead of REST. See here to details of Commands via Messaging And here for example of enabling the command client in App Service to use the MessageBus instead of REST. https://github.com/edgexfoundry/app-rfid-llrp-inventory/blob/3.1/res/configuration.yaml#L9-L11 The command client is accessible from the ApplicationService API and from the AppFunctionContext API

The above eliminate the use of REST in the internal communication between Device Services and App Services. Please see EdgeX MessageBus for more details about the internal MessageBus and options.

[jumpingliu]

close this issue as Lenny already provided the solution