|
|
|
date: Mon, 5 May 2008 12:59:28 -0700 (PDT),
group: microsoft.public.platformsdk.networking
back
Re: schannel app
Couple of thoughts; Kinda sounds like the connection is not being closed
when the app is terminated. I have had a similar issue where a passive
listener would daily use all of the ports on the server. It turns out that
the provider does not close the session connection when it times out. The
solution was to implement keepalives. If one sends a keepalive packet and
connection has been orphaned, one receives a 10054 error (at least in c#).
On the error, brutally close the socket connection.
If one app is opening 8-12 tcp sessions, and not closing them, I would
question the design of the app, but I know nothing of app. Maybe there is a
reason for this many sessions. But they should be cleaned up when the app
terminates.
wrote in message
news:9b3f4dc2-393b-4f72-b889-bb89fd9631f8@d45g2000hsc.googlegroups.com...
> All:
>
> I work for an application-service provider.. sort of... anyway. One
> of our many applications is actually a TN3270/telnet application which
> has hooks into a microsoft DLL to tunnel/encrypt the user traffic over
> SSL. So on the network, we see encrypted packets destined to/from
> port 443.
>
> This traffic hits a load-balancer that offloads the SSL encrypt/
> decrypt process.
>
> We are having an issue where, it seems, everything a single user does
> (like just login, or pull up a VT100 screen) ends up launching 8-12
> TCP connections. Over the course of a day 160 users launched upwards
> of 90000 tcp sessions.
>
> We have many thousands of users that use this application. Needless
> to say, this is starting to cripple our load balancer.
>
> Its my belief.. as an ex-programmer from a decade+ ago, that for the
> duration a user is logged into this app there should be a single TCP
> session.
>
> Does anyone know why this might be occuring or if there is someway of
> fixing this? I am speaking in the broadest possible terms here
> because I am a network engineer, not a programmer.
>
> Thanks for your help.
>
> Derick
> CCIE 15672
>
>
date: Tue, 6 May 2008 15:05:29 -0000
author: Steven
|
|