Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: writeserver api fails with error 64...

5 views
Skip to first unread message

ferrix

unread,
Mar 11, 2009, 12:21:40 PM3/11/09
to
Symc DLP wrote:
> i have an ms-isa 2006 enterprise edition installed with 1 array and have a
> web filter that registers for FORWARD_RAW_DATA and FORWARD_RAW_DATA_COMPLETED
> notifications. it aggregates the data when it receives the former and when it
> receives the later, it inspects the requests and sends the accumulated data
> to ISA via the Writeserver API. in my environment i see that this API fails
> quite reliably with error number 64 (net_name_deleted). i wonder what the
> probable causes might be. this frequently happens if i browse to sites such
> as - cnn.com, cnnsi.com foxnews.com and ibnlive.com (i.e. load these pages
> once and let it refresh; after a while, i see this error).
>
> i would appreciate any insights frm this group on this one.

If the remote server has closed the connection, this will happen.

If you wait too long to send data, the server may give up and close the
idle connection. I am not certain this is what you are seeing, but it's
a reasonable guess.

Symc DLP

unread,
Mar 13, 2009, 5:00:02 PM3/13/09
to
i did some more investigation on this and this is what i found out. i would
appreciate if someone could provide suggestions as to how ot handle this
scenario:

1) at time t, isa created a connection to the target server and forwarded
the data to it. the web-filter initiated this by reacting to
forward_raw_data_completed notification and invoking a writeserver api. the
http message that was sent had this in the http header:

Keep-Alive: 300\r\n

2. at time t+7 minutes later, the web filter got an
sf_forward_raw_data_completed notification again (after sending
sf_forward_raw_data) with the same filter context as #1 above. the
Writeserver API now tried to reuse the same connection that was set up in #1
above, and the target server (http) promptly sent back a tcp rst. this then
resulted in the error 64 that was seen on the client.

the connection management with the target web server isn't in the web
filter's hands (from what i can understand from the sdk documentation).
questions:

1) why is isa not closing down the connection after 5 minutes. this was the
last keep alive value that the isa sent to the server in the last message

2. the target server seem to be doing the right thing - i.e. closing down
the connection. can the web filter control this behavior in any way?

0 new messages