| At line 133 added 37 lines |
|
|
| !!Multiplexing Uploads:\\ |
| \\ |
| First you need to issue an command=openFile request. Include the upload_path parameter and a transfer_type parameter of upload or download. Also include upload_id (keep it short, alphabet characters, 6 chars is enough), and upload_size and optionally start_resume_loc if you want to resume from a particular byte position. CrushFTP will respond with the upload_id if the openFile succeeds, otherwise an error message. The response is in XML. Please note you can only have one multiplexed upload going at a time.\\ |
| \\ |
| {{{ |
| command=openFile&upload_path=/test.txt&upload_size=1024&upload_id=XhFtwp&start_resume_loc=0 |
| }}} |
| \\ |
| Now it’s ready to accepts chunks. To send a chunk, you send a POST to the server with the path of /U/transferid~chunk_num~chunk_size\\ |
| Then the body of the post is your chunk data. chunk_num starts from position 1, not zero.\\ |
| \\ |
| You signal the end of a transfer by issuing the closeFile request and providing the total number of chunks to be expected. The order of arriving chunks does not matter but you should not get more than 100mb off from the currently sent chunk or CrushFTP may start imposing speed limits to protect its memory usage. The response to this http command may be delayed as we are waiting for the chunks to come in. We may give you a reply about “Decompressing...” the file, which may or may not be the reason for the delay…it could be we are flushing to a S3 backend, etc. We will give you the md5 hash though once things are done as part of the XML response. You can keep calling the closeFile if needed if you got the “Decompressing…” message. lastModified is optional to set the modified time of the uploaded file. The server may ignore your requested time depending on server config.\\ |
| {{{ |
| command=closeFile&transfer_type=upload&lastModified=0&total_chunks= |
| }}} |
| \\ |
| \\ |
| !!Multiplexing Downloads:\\ |
| \\ |
| Issue the command=download with the transfer_type set to download to start a multiplexed download. include the path parameter and optionally the start_resume_loc if you are wanting to start the download at a particular byte position. download_id is an optional id (keep it short if you do include one, 6 chars alphabetical is enough), if you don’t include one, we create a 6 character random one for you. Please note you can only have one multiplexed download going at a time.\\ |
| {{{ |
| command=download&transfer_type=download&path=/test.txt&start_resume_loc=0 |
| }}} |
| \\ |
| To do a download chunk, it’s similar. But the path for the POST request is: /D/transferid~chunk_num\\ |
| \\ |
| If your HTTP response size is 0 bytes, that signals your chunk request was over the maximum possible and the file size is smaller. You should not request additional chunks as they will all result in 0 size responses too. Otherwise the HTTP response size is the size of that chunk you requested. If you try and request too far in advance of the chunk_num then what the server is allowing, you will get a 404 reply. Later when you request that same chunk, you will get the chunk instead of an error. So try not to get too aggressive or the server may not be able to satisfy your request. A 200 response code from the server indicates succession these requests, with either a chunk or a 0 byte response to indicate your done, and you can close the file if you have all your intermediate chunks.\\ |
| \\ |
| Closing the download is similar to closing the upload.\\ |
| {{{ |
| command=closeFile&transfer_type=download |
| }}} |
| \\ |
| It’s recommended to use at least 10 concurrent threads when doing multiplexed transfers.\\ |
| \\ |
