Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Breaking internet connection does not stop uploading #24

Closed
pawlowskim opened this issue Oct 16, 2015 · 6 comments
Closed

Breaking internet connection does not stop uploading #24

pawlowskim opened this issue Oct 16, 2015 · 6 comments
Assignees

Comments

@pawlowskim
Copy link

Hello,

Few days ago I started port tus java client to C#. When I finished I tested it on mobile devices. I have tested 2 scenarios:

  • Closing stream connection by killing application (S1)
  • Closing internet connection by turning off WiFi (S2)

In S1 Golang server close connection correctly, copy already send data to the file and set correct offset for future requests.
In S2 Golang server is waiting for resuming connection (it looks like). As far as I know it has default infinity timeout and is waiting for resuming connection too long. In that case If I want to re-upload the file I must start from the scratch (HEAD requests gives me 0 offset).

I don't know Golang so I'm asking you: Is there any way you can handle this scenario?

@pawlowskim pawlowskim changed the title Breaking internet connection does not break stop uploading Breaking internet connection does not stop uploading Oct 16, 2015
@Acconut
Copy link
Member

Acconut commented Oct 16, 2015

As far as I know it has default infinity timeout and is waiting for resuming connection too long.

Correct, if you don't specify any timeout in your Go HTTP handler a value of 0 is used for read timeouts, indicating that no upper limit is set at all.

However, you can define one by creating your own HTTP server:

server := &http.Server{
    ReadTimeout: 60 * time.Second,
    …
}
server.ListenAndServe(…)

The tusd command we provide doesn't do this but I will add an option for it and document this in the README.

@Acconut Acconut self-assigned this Oct 16, 2015
@LukaszMarchewka
Copy link

ReadTimeout is define timeout for whole connection (probably - i don't know go). So if everything works but takes more than 1 minute, server will terminate connection. Can you set timeout for idle?

@Acconut
Copy link
Member

Acconut commented Oct 16, 2015

http.Server.ReadTimeout is a wrapper around the net.Conn.SetReadDeadline method (https://golang.org/pkg/net/#Conn). More information can be found there.

So if everything works but takes more than 1 minute, server will terminate connection.

Yes, the connection will be closed if the read operation times out.

Can you set timeout for idle?

You can set a read and a write timeout. Is this not enough?

Anyway, I will do some testing on my site and then report back.

@LukaszMarchewka
Copy link

You can set a read and a write timeout. Is this not enough?

I don't know how long upload takes, sometimes 1 minutes is enough but other time I need much more.

@Acconut
Copy link
Member

Acconut commented Oct 16, 2015

Sorry, this fix is insufficient and does not fix your issue. I am working on it ATM.

@Acconut Acconut reopened this Oct 16, 2015
@Acconut
Copy link
Member

Acconut commented Oct 16, 2015

I was able to test your second szenario (Closing internet connection by turning off WiFi) and can confirm that the server does wait for data from the connection and therefore does not update the offset.

acd3a63 added a simple read timeout but not an idle read timeout. Latter is the correct version you asked for. This has been changed in 52eb00b and should be fine now.

@LukaszMarchewka: I don't know how long upload takes, sometimes 1 minutes is enough but other time I need much more.

I now added idle timeouts, so the total duration of an upload should not be relevant any more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants