Jump to content

IE7 issue/question


aahmad
 Share

Recommended Posts

Well, it looks like the problem may be specific to TCP window sizes - everything looks to be fine until the server (around 18 seconds in) starts shrinking the window size down eventually to 0, and then 53 seconds later resets the window size back to 32K and the transfer completes. I don't know specifically what on the client would cause the server to behave as if it's not keeping up with it's receive buffer, but I would suggest contacting the vendor (Winscribe) to see if there would be any known issues with this version of the app and IE7. Again, it is behaving as if it's overloading the server's receive buffer, and I can't think of anything client-side that would cause this (but it does appear possible).

Link to comment
Share on other sites


I have been working with them however so far have not found out the reason why this problem is happening. They are aware of that when IE6 is installed it is working fine. I know I am reaching here, but anyone aware of any settings in IIS to adjust?

Thanks!!

Link to comment
Share on other sites

It seems like a couple things combined:

The server's TCP window seems to behave somewhat normally. Perhaps it should scale down quicker (overloaded server perhaps), as the ACKs very quickly start to lag behind the packets being sent. That would likely prevent it from running into 0-sized window (as in, it can't process any more data right now), but it should still work despite of that, as you've noticed using the other box. Its size is probably kept to 0 that longer in the first capture because of all the network problems i.e. dupe ACKs (over 150!) and retransmits (tons of them too) -- those are definitely NOT normal. In the 2nd capture, there are exactly 0 dupe ACKs and no fast retransmits (that's what you expect to see normally, not 10%+ of "bad" packets like in the first capture)

If anything, I'd blame the connection going to the box that runs IE7. Try swapping around both boxes, and then try again. The box with IE7 just might now work, and the IE6 box fail.

Might be your network card, might be the wiring/patch cable, might be the switch port, ... Something's dropping packets somewhere, and a lot of them. Even the very first packet being sent (#8 in the capture), gets ACK'ed 3 times (packets #11, 14 and 16) -- the server probably "thinking" your box didn't receive them, as it didn't get the following packets, and then your box proceeds to retransmit the next 3 packets. And then it fails to ACK like 8 packets altogether (likely didn't receive them).... And the list goes on and on, until it ultimately fails. You can already tell this transfer is NEVER going to work. It's perfectly normal that your browser eventually gives up trying after all this.

So check your network. It's not the web browser at fault here. And it's most likely not the server either, seeing how it works alright with the other box (not scaling down the TCP window size as quickly as I'd like it to still isn't a big problem). Poking around the registry won't fix this either.

Edit: that barely looked like english, hopefully it's understandable now...

Edited by crahak
Link to comment
Share on other sites

It seems like a couple things combined:

The server's TCP window seems to behave somewhat normally. Perhaps it should scale down quicker (overloaded server perhaps), as the ACKs very quickly start to lag behind the packets being sent. That would likely prevent it from running into 0-sized window (as in, it can't process any more data right now), but it should still work despite of that, as you've noticed using the other box. Its size is probably kept to 0 that longer in the first capture because of all the network problems i.e. dupe ACKs (over 150!) and retransmits (tons of them too) -- those are definitely NOT normal. In the 2nd capture, there are exactly 0 dupe ACKs and no fast retransmits (that's what you expect to see normally, not 10%+ of "bad" packets like in the first capture)

If anything, I'd blame the connection going to the box that runs IE7. Try swapping around both boxes, and then try again. The box with IE7 just might now work, and the IE6 box fail.

Might be your network card, might be the wiring/patch cable, might be the switch port, ... Something's dropping packets somewhere, and a lot of them. Even the very first packet being sent (#8 in the capture), gets ACK'ed 3 times (packets #11, 14 and 16) -- the server probably "thinking" your box didn't receive them, as it didn't get the following packets, and then your box proceeds to retransmit the next 3 packets. And then it fails to ACK like 8 packets altogether (likely didn't receive them).... And the list goes on and on, until it ultimately fails. You can already tell this transfer is NEVER going to work. It's perfectly normal that your browser eventually gives up trying after all this.

So check your network. It's not the web browser at fault here. And it's most likely not the server either, seeing how it works alright with the other box (not scaling down the TCP window size as quickly as I'd like it to still isn't a big problem). Poking around the registry won't fix this either.

Edit: that barely looked like english, hopefully it's understandable now...

Well, I wish it was the network however the same machine with IE7 if I downgrade it to IE6 the problem disappears. Same goes for the other machine and throughtout the office. This issue that we have been encountering also does not occur in a single office, all of our 256k link offices. However anyone of those machines if you uninstall IE7 the problem disappears regardless of where the machine is in any of those offices.

Link to comment
Share on other sites

Well, I wish it was the network however the same machine with IE7 if I downgrade it to IE6 the problem disappears. Same goes for the other machine and throughtout the office. This issue that we have been encountering also does not occur in a single office, all of our 256k link offices. However anyone of those machines if you uninstall IE7 the problem disappears regardless of where the machine is in any of those offices.

You're assuming the developer of the app even tested his/her code on a slow link. Wininet doesn't control buffer size or whether or not it waits for a server ACK response, those are all handled at the winsock level (below wininet and outside the purview of Internet Explorer). Since upgrading to IE7 causes this behavior, this likely means your app vendor didn't write a winsock app, but an app that uses IE components. The networking component is wininet.dll, and there are no changes in wininet.dll with regards to network behavior between 6 and 7, so that leaves the developer's code - again, I'd wait for them to respond. What is happening would have little to do with the IE component themselves, and more to do with how the vendor is using them.

Also, if you install IE8 beta 2, does the problem show up there?

Link to comment
Share on other sites

Well, I wish it was the network however the same machine with IE7 if I downgrade it to IE6 the problem disappears. Same goes for the other machine and throughtout the office. This issue that we have been encountering also does not occur in a single office, all of our 256k link offices. However anyone of those machines if you uninstall IE7 the problem disappears regardless of where the machine is in any of those offices.

You're assuming the developer of the app even tested his/her code on a slow link. Wininet doesn't control buffer size or whether or not it waits for a server ACK response, those are all handled at the winsock level (below wininet and outside the purview of Internet Explorer). Since upgrading to IE7 causes this behavior, this likely means your app vendor didn't write a winsock app, but an app that uses IE components. The networking component is wininet.dll, and there are no changes in wininet.dll with regards to network behavior between 6 and 7, so that leaves the developer's code - again, I'd wait for them to respond. What is happening would have little to do with the IE component themselves, and more to do with how the vendor is using them.

Also, if you install IE8 beta 2, does the problem show up there?

Yes, I tried IE8 Beta 2 the other day and ran into the same problem. I was hoping it was something we could resolve as the developer unfortunately does not have an answer so far. Otherwise we will just have to work with a workaround such having the jobs from user pc's copied to a machine in our local office then uploaded from there.

Thanks again!!

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.


×
×
  • Create New...