locked
[WP7.1] Background File Transfer Service RRS feed

  • Question

  • When I add all 5 file transfers in the sample application, I find that only 2 transfers take place at a time. The 3rd one starts only after the 1st one is completed. Is it by design? What is the criteria to expect number of parallel transfers?
    Friday, June 3, 2011 2:43 PM

Answers

All replies

  • It is by design (scroll down to Limits).
    Friday, June 3, 2011 2:48 PM
  • Steve, as usual you are quite informative. Also here after I will check the documentaion, as per your signature line.

    However, I also noted that there is limit on total number transfers per device. Though it is quite high (500), the overloaded SystemException on BackgroundTransferService.Add() method will not be very helpful. They should have a separate exception to indicate when the device limit has been met. Actually it should be a property on the BackgroundTransferService class, so that one can check if limit has been reached even before attempting to add a request. That will even save some battery power.
    Friday, June 3, 2011 3:17 PM
  • Steve, as usual you are quite informative. Also here after I will check the documentaion, as per your signature line.
    I just read too much.  Then someone asks a question, and I know I've seen the answer somewhere...
    Saturday, June 4, 2011 11:29 AM
  • Though it is quite high (500), the overloaded SystemException on BackgroundTransferService.Add() method will not be very helpful. They should have a separate exception to indicate when the device limit has been met.


    Deciding when to add a new exception type is actually a tricky thing. On the surface, it can seem like adding a new exception type for every type of error condition is a good thing (then your app can handle each error separately and act accordingly) but in practice it is quite rare that adding a new exception type will actually help. The majority of exceptions are handled by one of the ArgumentException subclasses or InvalidOperation :-). In cases like this, there are no incorrect arguments and the program hasn't done anything wrong, so a different kind of exception is needed. However, a new exception should only be introduced if it adds significant value to the system (vs. just being noise). For example, imagine there was a SystemWideTransferLimitExceededException for this case... how would you handle it? There's nothing your app can do to recover, and there's nothing you can really ask your user to do either. The best you can do is catch SystemException (which should be quite rare in practice) and have a generic error that says "transfer service not availble; try again later" or something.

    Actually it should be a property on the BackgroundTransferService class, so that one can check if limit has been reached even before attempting to add a request. That will even save some battery power.


    Ideally yes we would make it easier to avoid the exception at all, but we didn't get there in Mango (plus there's a race condition here... at the time you check, there might be 500 outstanding requests, but one of them might complete immediately after you check... meaning that if you hadn't checked it would have succeeded, but since you did check you'll never even try :-) ).
    Saturday, June 4, 2011 9:10 PM
  • Though it is quite high (500), the overloaded SystemException on BackgroundTransferService.Add() method will not be very helpful. They should have a separate exception to indicate when the device limit has been met.


    Deciding when to add a new exception type is actually a tricky thing. On the surface, it can seem like adding a new exception type for every type of error condition is a good thing (then your app can handle each error separately and act accordingly) but in practice it is quite rare that adding a new exception type will actually help. The majority of exceptions are handled by one of the ArgumentException subclasses or InvalidOperation :-). In cases like this, there are no incorrect arguments and the program hasn't done anything wrong, so a different kind of exception is needed. However, a new exception should only be introduced if it adds significant value to the system (vs. just being noise). For example, imagine there was a SystemWideTransferLimitExceededException for this case... how would you handle it? There's nothing your app can do to recover, and there's nothing you can really ask your user to do either. The best you can do is catch SystemException (which should be quite rare in practice) and have a generic error that says "transfer service not availble; try again later" or something.


    That's why I used the word helpful. Due to the high limit, what we have is sufficient and it is not necessary to have a separate exception.

    Actually it should be a property on the BackgroundTransferService class, so that one can check if limit has been reached even before attempting to add a request. That will even save some battery power.


    Ideally yes we would make it easier to avoid the exception at all, but we didn't get there in Mango (plus there's a race condition here... at the time you check, there might be 500 outstanding requests, but one of them might complete immediately after you check... meaning that if you hadn't checked it would have succeeded, but since you did check you'll never even try :-) ).


    This sort of racing occurs everywhere. It is like my car fails the next day I got it from service. However, a background service may be allowed to hunt the limit. I know, as this is not an essential service, you may allow in future when a phone gets the TB range memory and THz clock speeds.
    Monday, June 6, 2011 4:05 PM