0

I have a client/sever application that communicates using HTTP. The server is on the other side of the Earth from some of the clients. The traffic that the server and client communicate is very low bandwidth.

At night the connections work reasonably well, not great, from anywhere on the planet but during the day the overseas links work poorly. Only the users living within the country are able to connect and all the others get TCP timeouts, retransmits, etc. I think that it's because of increased network traffic at peak hours causing latency.

Relocating the server is an expensive option. I'd like to provide a convenient solution for my users running the client without requiring them to reconfigure Windows timeouts, etc. I thought that one solution might be to have a proxy near the users that can accept the TCP connection and be more patient when connecting to the server. Or maybe switch to UDP. (UDP would be a pain, however.)

Maybe I have it all wrong? What can cause HTTP connectivity to be good from around 0:00UTC until 9-11 UTC and then be flaky the rest of the day? In Wireshark I see many duplicate ACKs, TCP retransmissions, lost segments, etc. Clients in the same country as the server don't complain. I've tested connecting to my server locally and via some online web proxies (hidemyass.com) and the former always works while the latter depends on time of day.

Edit: I switched from port 8080 to port 80 for the HTTP traffic and it seems to have helped! Is it possible that one of the routers along the way is treating port 80 traffic differently from port 8080? I also tried port 81, it also gets poor connectivity. Has anyone ever heard of something like this?

Eyal
  • 21
  • 2

2 Answers2

1

If the bandwidth utilization of your server does not peak at the worst connectivity times,
the problem may not at your server itself and very likely in the path; as you propose.

Have you checked with your ISP about this?
If you have a shared connection which peaks-out in the shared area, you could be loosing on your usable bandwidth and still not show a peak-utilization in your server measurements.

Since you find bad connectivity during your daytime, I would expect someone else near your uplink choking it -- sounds quite like a share link actively being used by your neighbors.

Update: to answer your question in the comment,

  1. Recheck your ISP aggrement -- what is the guaranteed upload and download bandwidth?
  2. Talk with your ISP about the problem (start from the customer support and escalate)
  3. Check other ISPs around you and try to talk with their sales people to describe this problem
    What is their opinion about it?
    What do they have as suggestions?
    (many times local people in the know have better information & solutions for such cases)
  4. Try to discuss a deal/agreement with another ISP that suits you.
    What you should be looking for is
    • upload and download bandwidth guarantee quotations (for the quoted price)
    • Proof of delivery which you can check whenever you want
      (things like MRTG data for your part of the link;
      Even if you have a shared link, the minimum bandwidth figures will be quotable and should be measurable)
  5. The previous point can also be discussed with your present ISP
  6. Fianlly, if you can get a good quote from another ISP,
    you can use that as a final-leverage on the present one.
    If things fail, you can take the effort of shifting to the new ISP.
nik
  • 7,100
  • 2
  • 25
  • 30
  • I'm betting nik is right and your upstreams are too heavily oversold & getting saturated. If that's the case switching to UDP won't help: It just shifts the burden of dealing with the dropped/lost/missing packets to your software instead of the network stack. – voretaq7 Feb 03 '10 at 03:54
  • So given that this is the problem, how do I solve it? Preferably without spending money. – Eyal Feb 03 '10 at 08:08
0

You need more information.

As a troubleshooting step I suggest a continuous tracert dumped to a file. Run it to several destinations (cities, continents) to isolate major Internet paths. If you have remote network resources available to you then you could run or schedule throughput tests to run to see what performance looks like at various times of day from various points around the world. iPerf is a good tool for this sort of test.

Then the next day view/plot the results to see if there are patterns indicating where the problem might be occuring. Of course, since trace route is low priority traffic and blocked by many firewalls, expect some amount of loss or loss at certain hops. If possible, run the same test from the reverse direction too. You may be faced with assymetric paths or other strange routing conditions. With that information you could be more specific in conversations with your ISP.

It may be that the ISP you use does not own the connection internationally, and it may be other ISPs which are creating the problem. Switching ISPs to one where they own the whole path to key countries/continents might be appropriate.

Neal

Neal
  • 141
  • 2