I’m uploading a SQL Server CE compact database file from a Windows Mobile application using a .asmx web service. I chunk the database into 1MiB blocks, reassembling the database on the server. Once the server is finished processing the database it is transferred back to the device using a similar process, driven by the mobile application. This works well but some of the users have ADSL connections that only allow for ~700Kb upload speeds. I would like to optimise the chunk size to ensure those users have the best upload experience possible. Is there an optimum chunk size for ADSL?
I’m uploading a SQL Server CE compact database file from a Windows Mobile application
Share
Different DSL links have different packet sizes depending on the provider, the network, the user’s preferences, and other factors. It’s impossible to predict from the server side what your users will have, and cumbersome to have them tell you.
Just send the data by TCP. The protocol is designed to self-adjust to the optimal packet size for client and server.
If you’re cutting your data up into (large) blocks to support resumed uploads, then you can work out how much time a customer would lose if they had to retransmit a block (eg if an upload is interrupted). So, if they were interrupted during the transmission of a 1MiB block, and they have a 700Kib uplink, then they lose just over one second if they have to retransmit the whole block. You can use that and your measured probability of a complete TCP connection failure — socket being closed and a block needing retransmission — to work out the expected retransmit overhead per file.
Since TCP failure is really rare (typically it’ll just buffer up and wait to send the rest of the data if a mobile connection bobbles), the rare 1sec hitch is probably unnoticeable unless you’ve got a realtime control loop. Which presumably the upload of an entire database is not.