On a slow connection, doing multipartHTTPupload, I get this a lot.

Is there a quick cure? 

 This looks like a timeout or worse it could be packet loss.  I would suggest upping the timeout on the webrequest object.  I think right now we go with defaults which are 90 seconds but unless the connection is completely stalled this will not be hit.  This suggests some serious issues.  My first suggestion outside of upping the timeout period would be to do some ping tests to see if you are dropping packets.  You can have a running ping with the command:

ping -t services.nirvanix.com

Regards,
    Barry R.

Dropped packets are a reality in the Internet. TCP/IP is designed to compensate for a lost packet, etc. How would i know? I've been writing routers, packet drivers and OSI client/server software for 15+ years.

The remote closing the connection because of a dropped packet is simply rude.

A lot of TCP implementations do this, and it's still rude. :) Any TCP/IP implementation worth anything will happily continue to work with packet loss, albeit a little more slowly. TCP/IP uses sequence numbers, checksum and a sliding window to allow for the possibility of dropped, corrupt and otherwise unsatisfactory packets to be resent.

 Closing my connection, 99.5% of the way through a 2 gigabyte file, because of a dropped packet is also rude. :)

The timeout is set to -1 (Infinite).

Note that on a faster connection, there appears (and I say appears) to be no problem with transmitting large files.

On my ping test, I pinged several thousand times with 0% packet loss (0 packets lost).

Just some data points.

JP
 

I never know the experience level of a developer so I have to get some base statistics.  It looks like you have a good handle on the problem of network loss.  We have some testing tools that will let me simulate slow network conditions.  I will put a slow down my connection and do some testing.  What would be helpful is:

What is your overall throughput (average kB/sec)?
Are you using a proxy, NAT, or other device between you and the internet?
What type of network are you on? (Modem, DSL, Cable, T1, Satellite, Wireless)

Let me know and I will be happy to help debug your connection failure.  Feel free to move this conversation to a private message if this information is not public such as IP Addresses or anything else you provide.

Regards,
     Barry R.

I'd like to submit a question.  You said you were using the multi-part upload in the first post and in your second post you said you were uploading a 2 GB file.  My question is... what size of the parts are you uploading at a time?  10 MB?  100k?

BarryR:

I never know the experience level of a developer so I have to get some base statistics.  It looks like you have a good handle on the problem of network loss.  We have some testing tools that will let me simulate slow network conditions.  I will put a slow down my connection and do some testing.  What would be helpful is:

What is your overall throughput (average kB/sec)?
Are you using a proxy, NAT, or other device between you and the internet?
What type of network are you on? (Modem, DSL, Cable, T1, Satellite, Wireless)

Let me know and I will be happy to help debug your connection failure.  Feel free to move this conversation to a private message if this information is not public such as IP Addresses or anything else you provide.

Regards,
     Barry R.

 
Throughput varies, upload varies between 128kb (s*ckful) to around 800kb (good).

No proxy, no nat, using Verizon Wireless Broadband (slow connection) and Comcast and AT&T for fast connection.

Off the wall thought: 

It might be that Verizon does some kind of congestion management, issuing RSTs when a particular segment gets saturated. This is a well known (and extremely rude) way to cheaply keep a link from being dominated by a single user. :)

There are better ways to manage QOS. For TCP, all one need do is increase latency a bit and throughput will drop. Due to the nature of TCP, one only need hold back three packets (per connection) at any one time to create delays as long as desired and drop throughput to any desired level with no packets lost.

Back on point, I don't think it's a major issue, after all. Sorry if I came off rude, it's been a long, long week.

 
JP