Not sure how the debug GUI exe works but I found a solution for the
service:
In ...WndControl.pas,
const
TIcsWndControlVersion = 110;
CopyRight : String = ' TIcsWndControl (c) 2002-2008 F. Piette V1.10
';
WH_MAX_MSG = 400; <== MODIFIED THIS from 100
so that it would create less windows per same number of messages. With
this
change, My also ICS stress tester can open > 15k connections concurrently.
In a real life case, since there will not be a stress tester on the same
machine, I think it is ok. This must be a non-paged RAM drought issue...
Could you make WH_MAX_MSG a property so that each time users update ICS,
they would not need to change ICS source?
It is likely that Windows has different settings for a service application
and a GUI application. Since a GUI application is likely to use a lot of
windows (visible or not), probably Windows size his internal tables
accordingly. A GUI application has a default 10.000 handles allowed. This is
why I created TIcsWndControl in the first place. This allow to open more
concurrent sockets since with TIcsWndControl a single window handle a lot of
sockets (100 by default) and you don't run out of handle anymore.
This article could be a starting point for you:
http://weblogs.asp.net/mikedopp/archive/2008/05/16/increasing-user-handle-and-gdi-handle-limits.aspx
And also this one: http://www.google.be/search?q=windows+handle+limit+10000
--
francois.pie...@overbyte.be
The author of the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)
http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
