Simplest way is using netstat -a from "DOS prompt". Client socket ports, IIRC, run from 32768 thru to 65535, hopping up 2 for each new connection. (So there might only be 16k not 64k ports available. And TCP stack might have other internal limits) Netstat will show ports that have just been used, closed and not reusable yet - in a TIME_WAIT or CLOSE_WAIT state. There might be a programmer API for this, but the default search result still seems to be netstat.
Is it not possible to merge multiple connections into one longer lasting one and see if this resolves the issue? Another thought is "DoS" - denial of service. After reading up a bit, seems a lot more involved there than I first thought. But you could be triggering one of the TCP/IP vulnerabilities, not sure exactly which one, most likely something similar to sockstress. Stephen Dickason Senior Developer - Managed Services Email: sdicka...@elcb.co.za ELCB Information Services (Pty) Ltd Customer Service Email e...@elcb.co.za * www.elcb.co.za E A S T L O N D O N Tel: +27(43) 704 0700 Fax: +27(43) 704 0701 J O H A N N E S B U R G Tel: +27(11) 879 6179 Fax: +27(11) 454 0384 P O R T E L I Z A B E T H Tel: +27(41) 373 0529 Fax: +27(86) 650 0135 Disclaimer -----Original Message----- From: TWSocket [mailto:twsocket-boun...@lists.elists.org] On Behalf Of Doug Billi Sent: 13 August 2014 09:27 PM To: ICS support mailing Subject: Re: [twsocket] Handle Leak I keep stats on the number of concurrent connections open in both the client and server, but I never see them build up -- they are processed as fast as they are sent. In our application, where this first occurred, we were using LoadUI to send 1 connection per second. Is there a way to monitor the number of available ports? Thanks, Doug -----Original Message----- From: Stephen Dickason [mailto:sdicka...@elcb.co.za] Sent: Tuesday, August 12, 2014 11:23 PM To: ICS support mailing Subject: Re: [twsocket] Handle Leak I could be wrong and haven't time to scan your code. But there is an error condition that will arise if all the client ports are used (and to be tautologous) no more are available; 64k ports is a lot so hardly happens. It would most likely happen in the conditions you describe - none for period of time sudden increase in errors (depending on resilience of code). If I'm reading your usage of ports correctly - 40 connections a second - and the necessary wait time after port close - you possibly hitting it. Stephen Dickason Senior Developer - Managed Services Email: sdicka...@elcb.co.za ELCB Information Services (Pty) Ltd Customer Service Email e...@elcb.co.za * www.elcb.co.za E A S T L O N D O N Tel: +27(43) 704 0700 Fax: +27(43) 704 0701 J O H A N N E S B U R G Tel: +27(11) 879 6179 Fax: +27(11) 454 0384 P O R T E L I Z A B E T H Tel: +27(41) 373 0529 Fax: +27(86) 650 0135 Disclaimer -----Original Message----- From: TWSocket [mailto:twsocket-boun...@lists.elists.org] On Behalf Of RTT Sent: 12 August 2014 07:43 PM To: ICS support mailing Subject: Re: [twsocket] Handle Leak On 12-08-2014 16:33, Doug Billi wrote: > There are no memory leaks, and no other handle leaks, other than > security-context tokens. Testing here and I'm not seeing any token type handle listed in the process explorer list of open handles for the server or client application. The total number of handles is also stable for client and server. Using your suggested 40 connections per second, and also XE2 -- 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 -- 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 -- 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
