P
Philip Spencer
We are seeing exactly the same symptoms upon upgrading our
POP server to a faster machine.
It appears to be a timing issue or some sort of race
condition in Outlook (or in Windows). If I edit the source
code of our POP server and insert a 1 millisecond delay
before each output statement, the problem goes away. In
fact, even putting some heavy load on the network
interface of the server is also enough to make the problem
go away.
A dump of the network traffic between the Outlook client
and the POP server reveals the following behaviour:
(1) username and password requested for and supplied.
(2) Outlook client to POP server: "STAT"
(3) POP server to Outlook Client: ACK's #2, sends "+OK 0 0"
(4) Outlook client to POP server: ACK's #3.
There is no further traffic.
When I make the POP server delay 1 millisecond before
sending out packet #3, then the behaviour modifies to:
(4) Outlook client to POP server: ACK's #3, sends "UIDL"
and the conversation continues.
This is not a problem on the POP server end: it is simply
waiting for Outlook to continue the conversation.
This is not a problem of packets getting lost on the
network: packet (3) did not get lost, because the Windows
client acknowledges it. And, if Outlook's "UIDL" request
had gotten lost on the network, a retransmission attempt
would have shown up sooner or later.
I think the most likely explanation is the following:
A Outlook sends the "STAT" command.
B Outlook then starts to wait for a response.
But the response was already received IN BETWEEN
A and B, before Outlook was prepared to receive it,
and got lost or discarded as a result.
I have no idea how the internals of Outlook work but hope
this information will be enough for someone who does to
track down the problem.
In the meantime, I guess we're just going to have to keep
those sleep statements in our POP server so that it's slow
enough for Outlook's liking.
If you're not working with an open source POP server,
you're probably out of luck unless you can introduce some
extra routing into your network to slow down the traffic
enough.
- Philip.
POP server to a faster machine.
It appears to be a timing issue or some sort of race
condition in Outlook (or in Windows). If I edit the source
code of our POP server and insert a 1 millisecond delay
before each output statement, the problem goes away. In
fact, even putting some heavy load on the network
interface of the server is also enough to make the problem
go away.
A dump of the network traffic between the Outlook client
and the POP server reveals the following behaviour:
(1) username and password requested for and supplied.
(2) Outlook client to POP server: "STAT"
(3) POP server to Outlook Client: ACK's #2, sends "+OK 0 0"
(4) Outlook client to POP server: ACK's #3.
There is no further traffic.
When I make the POP server delay 1 millisecond before
sending out packet #3, then the behaviour modifies to:
(4) Outlook client to POP server: ACK's #3, sends "UIDL"
and the conversation continues.
This is not a problem on the POP server end: it is simply
waiting for Outlook to continue the conversation.
This is not a problem of packets getting lost on the
network: packet (3) did not get lost, because the Windows
client acknowledges it. And, if Outlook's "UIDL" request
had gotten lost on the network, a retransmission attempt
would have shown up sooner or later.
I think the most likely explanation is the following:
A Outlook sends the "STAT" command.
B Outlook then starts to wait for a response.
But the response was already received IN BETWEEN
A and B, before Outlook was prepared to receive it,
and got lost or discarded as a result.
I have no idea how the internals of Outlook work but hope
this information will be enough for someone who does to
track down the problem.
In the meantime, I guess we're just going to have to keep
those sleep statements in our POP server so that it's slow
enough for Outlook's liking.
If you're not working with an open source POP server,
you're probably out of luck unless you can introduce some
extra routing into your network to slow down the traffic
enough.
- Philip.