You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recently, gRPC is gaining more and more popularity in the V2Fly community, but its throughput performance and resiliency to connection interruption are not even on par with other transport methods provided currently by v2ray-core.
This proposal is meant to discover possibilities of using multiple bidirectional streaming RPC channels to improve the overall performance of gRPC.
Specification
An extra option must be provided in grpcObject to enable the multichannel feature.
multiChannel: an int option.
Value 0: disable multichannel.
Any value between 1~7: {multiChannel} extra channels will be created with serviceName: $"{originalServiceName}-{sequence}"
When the multichannel feature is enabled, v2ray-core's gRPC dialer will load-balance extra channels together with the original channel and send data overall connections in the pool.
Possible benefits
Currently, with only one gRPC channel, if it is forcibly closed or reset due to network fluctuations or interventions, the connection must be re-established and until then the lost packet may be resent. Due to the above reason, gRPC has a poor performance when the network environment is unstable or the intervention of the CDSG is strong. With this feature, even if one of the channels is interrupted, there is still a channel left for the lost data to be resent immediately.
(Special topic) Each gRPC channel uses 0 or more HTTP/2 connections and each connection usually has a limit on the number of concurrent streams. When the number of active RPCs on the connection reaches this limit, additional RPCs are queued in the client and must wait for active RPCs to finish before they are sent. Applications with high load or long-lived streaming RPCs might see performance issues because of this queueing. There are two possible solutions:
Create a separate channel for each area of high load in the application.
Use a pool of gRPC channels to distribute RPCs over multiple connections (channels must have different channel arguments to prevent re-use so define a use-specific channel argument such as channel number).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Introduction
Recently, gRPC is gaining more and more popularity in the V2Fly community, but its throughput performance and resiliency to connection interruption are not even on par with other transport methods provided currently by v2ray-core.
This proposal is meant to discover possibilities of using multiple bidirectional streaming RPC channels to improve the overall performance of gRPC.
Specification
An extra option must be provided in
grpcObject
to enable the multichannel feature.multiChannel
: anint
option.0
: disable multichannel.1~7
:{multiChannel}
extra channels will be created withserviceName: $"{originalServiceName}-{sequence}"
When the multichannel feature is enabled, v2ray-core's gRPC dialer will load-balance extra channels together with the original channel and send data overall connections in the pool.
Possible benefits
Currently, with only one gRPC channel, if it is forcibly closed or reset due to network fluctuations or interventions, the connection must be re-established and until then the lost packet may be resent. Due to the above reason, gRPC has a poor performance when the network environment is unstable or the intervention of the CDSG is strong. With this feature, even if one of the channels is interrupted, there is still a channel left for the lost data to be resent immediately.
referring to gRPC Performance guide
Beta Was this translation helpful? Give feedback.
All reactions