I only had about an hour to program today, so not much that I could set up. I was reading the logs and saw that the current CVS could be used, at least for C code, by declaring
void __crtmain() {SYS_PreMain(); main(NULL, 0); }
I have only tried this with my lighting example code, which worked. Since that is one of my more complicated programs, it seems to be working now. I haven’t tried any other wii intensive examples(in terms of using wii-specific code that is new to libogc).
I explored the format of FTP to see how well it would work for what I wanted in a file transfer program on the wii. It appeared to be simple at first, consisting of a requirement of 3-4 character commands that had to be parsed and responded to/settings changed. This itself is not too complicated, as it would just require a structured switch style routine that can be made or fabricated for c using a script.
I attempted to find a pre-made one that was stripped down as possible in java so that I could just port the code over to c based on the logic it was composed of. I found one called MyFtpD that looked promising. In actually running it, however, it revealed a couple issues that I’d need to resolve before it became a catch-all solution for transferring to the wii.
FTP has two methods it uses for communication/transfer, active and passive. These detail how the two socket channels will be set up for future commands. From my understanding, this allows maintaining one channel for communication and a secondary channel for data handling. Issues for data requests or low data information occur on one channel (change director, up, down, give me info), and large data request (file transfer, directory listing, upload) occur on the other channel.
I like this structure, and I know it may be re-inventing the wheel, but I think that with my current skills I’d prefer something that was more tailored to single-user file transfer. The idea of 2 channels, one for data and one for quicker and shorter commands, seems like a good implementation that wouldn’t take too much work. One channel the command channel could be polled every couple packets during a data transfer to give status on completion, or errors, or accept kill commands should you make a mistake or hang (ping/pong).
The main steps that I see are:
1. list directory, stat file, updirectory, change directory -first things needed, and even then you are in good shape
2. get file, send file,delete file – at this point you are almost fully featured
3.rename file, rename dir, make dir – some final touches that allow client to batch upload/download
10 instructions, all short
FORMAT:
1 – List Directory : no param. Return: (channel1)(long count) (channel2)(list: (u8 type)(cstring name))
2 – Stat: (long fileIndex) Return: (long size)(cstring name)(long create_date)(etc)
3 – Up Directory : no param. Return: (channel1)success/fail
4 – Change Directory : (long index). Return: (channel1)success/fail
5 – Get File: (long index). Return: (channel1)(long size) (channel2) (raw data)
6 – Send File: (channel1)(c_str name)(long size) (chanel2)(raw data) Return:(channel1)success/fail
7 – Delete File: (index) Return: (channel1)success/fail
8 – Rename File: (index)(c_str name) Return: (channel1) success/fail
9- Rename Dir: (index0(c_str name) Return: (channel1) success/fail (basically same)
10- Make Dir: (c_str name) Return: (channel1) success/fail
