some opnion...

[jdev4u]

1.how about reuse port and multiprocessing same port by cpu core instead of using a multi channel? 2.maybe extend ephemeral_key_source.h for use key cache, then possible more tps(rps) and no crash...

[serialx]

Hello, thank you for your feedback. Let me share my opinions about the subject.

1.how about reuse port and multiprocessing same port by cpu core instead of using a multi channel?

I think it's an interesting idea. But since the QUIC packets are load balanced using QUIC CID, multi channel CID based load balancing is a necessity. If it's guaranteed that a unique CID packets arrive at the same receiving socket, it would be possible. But I think the packets would arrive randomly across multiple listening sockets, thereby requiring custom load balancing anyways.

2.maybe extend ephemeral_key_source.h for use key cache, then possible more tps(rps) and no crash...

I will have a look into that! Did you experience crashes because of key source? If so, please share more information. I would be glad to look into that problem.

Thanks!

[serialx]

More thoughts about suggestion number 1.

Since the origin source IP/port might change in the case of mobile/cellular network change. (ie. Wifi being turned off during requests) Multi-process load balancing would not be feasible. Kernel load balance using the source IP/port. When user's source change, the kernel will load balance that packets to a different process. And the connection would drop. :(

[serialx]

• Number 1 fixed in devsisters/gospdyquic@7c2fe05a0725afe50953fd164da8980d9a9e085a
  • I went to a single process multiple socket approach to improve socket lock contention.
• Number 2 fixed in ab7e25b305da602e031e224782b42deafd2b5911
  • EphemeralKeySource implemented and cached key for 10 seconds.

Thank you for your feedback! It was great suggestions.

[jdev4u]

great job!!! Thank you...