gnet icon indicating copy to clipboard operation
gnet copied to clipboard

Cap the resource used by each connection

Open lming opened this issue 3 years ago • 2 comments

it's important for gnet to cap per connection resource usage as other systems do, for example Linux kernal has options for per connection send/recv buffer size. In gnet's case, per connection's send buf size and async tasks number should be capped.

Suggestion: to expose per conn options MaxPendingWriteTasksPerConn and MaxWriteBuffSizePerConn When client calls AsyncWrite:

  • The conn's NumPendingTasks is checked, returns error if it reaches the limit
  • The conn's write buf size is checked (TotalWriteBuffSizeInPendingTasks + len(c.outboundBuffer) < `MaxWriteBuffSizePerConn), returns error if the write buf size reaches the limit

With this change, the caller is aware of the error immediately when one of the two limits is reached. I am not sure how difficult to do the buf size check within AsyncWrite in a lock-free fashion though.

lming avatar Jul 07 '21 23:07 lming

Thanks for opening a new issue. The team has been notified and will review it as soon as possible. For urgent issues and priority support, visit https://xscode.com/panjf2000/gnet

xscode-auto-reply[bot] avatar Jul 07 '21 23:07 xscode-auto-reply[bot]

With this change, the caller is aware of the error immediately when one of the two limits is reached. I am not sure how difficult to do the buf size check within AsyncWrite in a lock-free fashion though.

Maybe consider not doing it in a synchronous way but asynchronous approach: callback or channel, I don't want this change to cause any data race or introduce a mutex.

panjf2000 avatar Jul 10 '21 11:07 panjf2000