FTP Server and RedFly-Shield Socket class

I have been using Skewworks FTP server class to test my simple RedFly.Socket class. I got to a point where the FTP server was able to respond to a few FTP commands, including using 'get' to retrieve a file from the FEZ Domino SD card. But hit a snag when trying to send a file from the PC to the FTP server. It was becoming obvious that my simple implementation of a Socket class needed to have higher level functionality. Two thoughts were; implementing meaningful exception handling and function parameter checking, and hide in a lower layer the internal socket handling within the RedFly-Shield.

My search lead my to quite a few differing implementations of System.Net.Socket class library functions. Eventually I was draw to the implementation in the OpenSource Mono .Net core.

I've heavily refactored the RedFly.Socket class, and tweaked the FTP server and RedFly-Tester solution (make sure to grab at least r106 from the GoogleCode SVN repository).

As of r106 of the repository, the FTP server can perform most of the commands. 'get' and 'send' are quite limited at the moment though. They are restricted by the number of bytes for a file transferred.

I've got two new steps to take now -

1. Try the RedFly.Socket class with other example code, such as HTTP client and server, DNS lookups, NTP sync.
2. Finally update the UART reception handling.

RedFly-Shield Socket class and FTP Server

After coming back from a short vacation, I thought I'd add an update to describe my progress with the Watterott Electronic RedFly-Shield.

In the previous blog post I describe the success I've had with setting up the C# Shield class to initialise and setup the RedPine Signals WiFi module (RS9110-N-11-22). Once I was happy with this class I moved on to looking at how to support the 8 sockets on this WiFi module.

Skewworks had added a FTP server class to the code repository over at TinyCLR.com Looking through this, and other network code, it seemed obvious to create a custom Socket class for the RedFly-Shield. I started with the System.Net.Sockets class as a template and began fleshing out the necessary class functions.

After implementing the bare essential Socket functions, I was surprised how quickly it was to get the FTP server class working. A nice feature of creating a new RedFly Socket class is that the only change needed to Skewwork's FTP class was the addition of the following code;

using Socket = RedFly.RedFlySocket;

So right now the RedFlySocket classes can be used to create listening Sockets (only tested TCP ones), accept incoming connections on those sockets, and receive data from a connected host. This initial setup however is able to allow a host PC to connect to the FTP server running on a FEZ Domino, complete a handful of FTP commands (pwd, cwd, etc.), and receive a file located on the FEZ Domino SD card.

A much harder task is to flesh out the RedFlySocket.Send functions. I've come across something odd with my fairly synchronous UART data reception. So now I need to work out a different strategy for handling incoming UART data from the RedPine WiFi module.

Over on my GoogleCode SVN repository, revision 99 of the RedFly class library ties in with this blog post;
http://code.google.com/p/burt/source/browse/trunk/FEZ+Domino+Projects/RedFly/

A RedFly-Tester solution exists that creates a listening Socket on port 23, and simply acknowledges a host trying to telnet to the RedFly Shield;
http://code.google.com/p/burt/source/browse/trunk/FEZ+Domino+Projects/RedFly-Tester/

Revision 96 of the RedFly FTP server solution also ties in with this blog post;
http://code.google.com/p/burt/source/browse/trunk/FEZ+Domino+Projects/FTP+Server+Test/