Furcadia/Specifications/Fileserver
From FurcadiaWiki
Contents |
Thanks to...
- Trek, from which these fileserver specs have come from.
- Protocols updates by Kunnis
Connecting
When connecting to the fileserver, you will recieve this message:
10 Welcome to Furcadia file server, proceed to id.
The only(?) valid command you can send in response to this is the following:
RC NAME PASSWORD DREAM_ID STARTPOINT SENDAHEAD CHUNKSIZE
NAME and PASSWORD are your normal Furcadia login. DREAM_ID is the ID from message 61:81 (??) in the normal game server protocol, which begins with td for dreams, or pp for portraits. The number after pp for portraits other than Silver Sponsor portraits can also be gained from the portrait page[1]: it is the number with ".prt" after it.
The STARTPOINT (usually 0) is the offset (In bytes?) into the file where transmission will start. This allows for file resuming.
SENDAHEAD defines how many the server will send before waiting for the user to catch up. The file server is currently buggy, and can't send more then about 3 chunks at once. If you follow the desgin that DEP uses, you will never go outside of that limit, unless you upgrade to another design that does send-ahead.
CHUNKSIZE is the size of chunks the server will send. Normally this is 4096 bytes. (This means that the TCP/IP protocol may break it up into 2 packets of size 1460 and 1 packet of size 1176.)
Example strings would be:
RC ~MyName ~MyPass td2316690942 0 2 4096 RC ~MyName ~MyPass pp493 0 2 4096
[The default Furcadia client uses a different authentication method when uploading files, please see below for more information]
Downloading
If you're lucky with connecting, you'll get the following response:
44 FILESIZE FILETYPE CHUNKSIZE 0
FILESIZE is the filesize. FILETYPE is the type of the file - 2 is a dream, 3 is a portrait. CHUNKSIZE is the size of the chunks like you specified previously. Again, the meaning of the 0 is unknown.
The fileserver will then proceed dumping the requested binary data on you.
The whole file is sent in chunks. Each chunk is CHUNKSIZE bytes, and begins with a 10 byte chunk header. You are required to send a confirmation that you received each chunk before it will send you the next one. The last chunk is padded with 0's so that it is a full CHUNKSIZE bytes in length.
Each chunk header is 10 bytes total:
SCXXXXYYYY
The first 2 bytes are just the characters SC (0x53 0x43) followed by 4 bytes for the "chunk number". The "chunk number" starts at 0 for the first chunk, and is incremented for every chunk after that. The last 4 bytes there (YYYY) I'm not sure what it is. Following the 10 byte header is (CHUNKSIZE - 10) bytes of data for the actual file.
You simply append the data portions of these chunks together one after another, to get the resultant file. Do not append the padding of 0's in the last chunk though. You can determine how many bytes of real data the last chunk holds based off the FILESIZE that was given to you previously.
There should be exactly ceil(FILESIZE/(CHUNKSIZE-10)) chunks total.
The acknowledgement to send (in plain, cr terminated text) after a chunk has been fully received is:
PKOK CHUNK_NUMBER
Where CHUNK_NUMBER is the number of the chunk, from the chunk's header.
Most invalid input at this point will be ignored
After the last chunk is received and acknowledged, send the server:
BYE
and it will respond with:
99 Log out sequence initiated.
And now you have the "Dream File".
Resuming a download
Pass the server a Startpoint of how many bytes into the file you respond. The last parameter of the 44 message will specify which packet number that the resume is going to start on. You should seek packet number * packet size bytes into the file before writing. --Note from Kunnis: Someone please confirm this. These are based on some guesses I made.
Uploading
Sample upload session:
CM -> Client to Main server CF -> Client to File server MC -> Main server to Client FC -> File server to Client
CM rgate MC ]u CF Client initiates connection to file server FC 10 Welcome to Furcadia file server, proceed to id. CF USER name FC 20 Username received, continue to pwd. CF PASS password FC 30 User logged in, proceed. CF SETR 0 FC 90 UFP set. CF SEND filename size FC 50 0 Ready to receive the file. CF SNCSEND tdcode 0 CF SC<4 byte chunkid><4 byte CRC32 of chunk data><chunk data, 0 padded> * may span multiple packets FC 55 chunkid FC 59 File transfer complete. CF BYE FC 99 Log out sequence initiated. CM tdgate tdcode
Though I've shown only one of each above, there may be more than one chunk per file and more than one file per upload session. I suspect you may be able to upload more than one dream per session too if you use different td codes in the SYCSEND tdcode 0 command.
SETR 0 starts each individual file upload.
SYCSEND tdcode 0 tells the server which dream you're uploading files too.
55 chunkid is just like PKOK. It informs the client that the server has received the chunk and is ready for another one. The client will send up to 3 chunks before waiting for a 55 chunkid line. The server usually waits until it's received all three chunks, then sends all three 55 chunkid lines together in one packet.
I've observed both 1024 and 2048 byte chunks, though only one size chunk per file. I see no method for informing the server of the chunk size, though it seems to be based on the file size anyway (I think anything smaller than 1015 bytes would get a 1024 byte chunk and anything larger than 1014 gets 2048 bytes). The chunk size includes the chunk header.
A dream upload sends two .rch files: t2rca<id+2>.rch and tdrca<id>.rch, where <id> is a six digit number. The first file contains default.txt and the second contains everything else.
I do not have any information on how the td code or the numbers in the two filenames are created.
The td code is later used by the server to cause the client to download the dream using this command:
]q td<tdcode> <tdcode>
