[OpenAFS-devel] Re: idle dead timeout processing in clients

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF0A6A3C5C1910476708667CD
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 12/9/2011 1:27 PM, omalleys@msu.edu wrote:
>=20
> I also just remembered, There is something about windows xp's network
> stack isn't as robust (nt was worse) and does have a tendency to drop
> packets off the queue (oldest first), versus unix which does just the
> opposite. If you make a request from a windows client to your unix
> server, then the windows network stack gets overloaded with network
> requests or the unix server is overloaded busy already, then windows
> times out the oldest request, and then the unix server tries to respond=

> to the old request, which windows disregards as irrelevent because it i=
s
> already off its queue, this could be causing spikes in the AFS
> processes. (I can't remember if this just affects tcp or it affects udp=

> also.)

I'm not sure what the above has to do with this thread.  The problems
with idle dead are strictly limited to Rx and the service that runs atop =
it.

The Windows AFS client unlike the Unix AFS client is "rx hot threaded"
just as the AFS file server is and is less likely to drop incoming
packets because it has more than one listener thread to read and process
them.

The order that packets are dropped on a socket on the Windows platform
is determined by the application with the SIO_ENABLE_CIRCULAR_QUEUEING
ioctl().  The size of the packet buffers are also set by the
application.  The rx stack on Windows configures both of these values.

Rx connections are reliable.  The retries are performed within Rx and
not by the underlying UDP/IP layer which is a connectionless.  An Rx
sender does not drop packets from its transmit queue until the peer has
issued both a soft ack (packet received) and a hard ack (packet
processed).  Regardless of Microsoft's IP packet buffer processing, it
does not have an impact on AFS in the way that you describe.

Jeffrey Altman


--------------enigF0A6A3C5C1910476708667CD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJO4lgKAAoJENxm1CNJffh4SAoH/iHt4NjCAFqp0ksSjzTt4+sJ
csecNH+ZepfVm4D7KK3QMiTYQ+YuA4jFKIny9zdyHCp4+6tttFkwWkSNGp/NY8qa
nteuKQsWOgkgg4+ch7ArEtJp0aNV1LLWpfxzoFJcvKIoqBnnYkENk2hg5Csj0ALr
Z9ZV1JgHtUM9wJ7e3NdoATxJv9Ef5NfMeHIYWrq3i6o3A7BZAMJp+5Gn96sBQDJ5
3TVBhdb83PGQekG6vXtp9b54D7MZ+Nr6oFe6JN+0gWOjRWlDqN1tPuapxJK7bOkS
e18k3Z0/3WTkG2lm7BYFXpu87nUmhXr2yLxqYt4UVOhpVWwkJDqdTKmarnsXbZE=
=63b8
-----END PGP SIGNATURE-----

--------------enigF0A6A3C5C1910476708667CD--