Am Donnerstag, 31.10.02 um 19:11 Uhr schrieb Joshua Coombs:
Yes, we've raised it to 3000 for most tests. If possible could you set it up such that you can choose between 'unlimited' clients or a hard max at compile time? Being able to tune mem usage based on a max client count is turning out to be a good tuning tool for the 386's we're deploying on. Larger machines may not need the limit. We prefer a last check to keep a machine from sprialing out of control.
An optional hard limit will be no problem to implement and seems quite important for me. Therefore it will be there :-)
Anoter problem is the already implemented dynamical allocation of channel structures: there is _no_ hard limit (except of out of memory) actually. And a hard limit would cause trouble in the network by bringing servers out of sync (server A has channel X, server B not ...).
My upcoming patch for "unlimited" connections will add a generic API to access the connection structures (actually an array is accessed directly -- no good for dynamic allocation) but internally still allocate memory "en block": if there is no space left for a new connection, a bigger memory block is requested, everything copied and the old one freed.
Disadvantage: memory will never be freed (no problem on modern systems with intelligent virtual memory management).
Advantage: the new API functions can internally still use the old array-based functions to access the connection structures.
"Someone" has to fix this up in another patch ... ;-)
Regards Alex