Cap the resource used by each connection

[lming]

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.

[xscode-auto-reply]

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

[panjf2000]

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.

[github-actions]

This issue is marked as stale because it has been open for 30 days with no activity.

You should take one of the following actions:

• Manually close this issue if it is no longer relevant
• Comment if you have more information to share

This issue will be automatically closed in 7 days if no further activity occurs.

[github-actions]

This issue is marked as stale because it has been open for 30 days with no activity.

You should take one of the following actions:

• Manually close this issue if it is no longer relevant
• Comment if you have more information to share

This issue will be automatically closed in 7 days if no further activity occurs.

[github-actions]

This issue was closed because it has been inactive for 7 days since being marked as stale.

If you believe this is a false alarm, please leave a comment for it or open a new issue, you can also reopen this issue directly if you have permission.