Hi All
I got my gadgeteer hardware few weeks ago. I build some test applications and the development speed was incredible. But if I tested the Ethernet module I missed something. No FEZ way for TCP and UDP communication?
So my first gadgeteer project was born
The .net Micro Framework offers full TCP support so the basic implementation was really fast. I implemented some features to read and write data in a very simple way and the most important thing is that is compatible to the .MS .net on the client side.
At the current state of the project I implemented:
[ulist]
[]Binaryreader for .net Microframework ( compatible to .net version but no decimal support )
[]Binarywriter for .net Microframework ( compatible to .net version but no decimal support )
[]TCPServer for .net Gadgeteer as Extension to Networkmodule
[]UDPServer for .net Gadgeteer as Extension to Networkmodule
[/ulist]
The main focus is that its easy to use and I think I succeeded
//Initialize server
var udpServer = ethernet.CreateUDPServer(udpPort);
udpServer.DataReceived += new GTM.Module.NetworkModule.UDPServer.DataReceivedEventHandler(udpServer_DataReceived);
var tcpServer = ethernet.CreateTCPServer(tcpPort);
tcpServer.DataReceived += new GTM.Module.NetworkModule.TCPServer.DataReceivedEventHandler(tcpServer_DataReceived);
//Start server
udpServer.Start();
tcpServer.Start();
TCp Sample
private void tcpServer_DataReceived(System.Net.Sockets.Socket sender, GTM.Module.NetworkModule.TCPServer.DataReceiveEventArgs e)
{
//Read a 32bit integer
int command = e.Reader.ReadInt32();
switch (command)
{
case 1: var text = e.Reader.ReadString();
Log(text);
break;
case 2:
byte red = e.Reader.ReadByte();
byte green = e.Reader.ReadByte();
byte blue = e.Reader.ReadByte();
display.SimpleGraphics.BackgroundColor = GT.Color.FromRGB(red, green, blue);
display.SimpleGraphics.Redraw();
break;
}
}
NOTE: This Release is the first Alpha Version! It is working but only tested with FEZ Spider Hardware. The reason for releasing this project in an Alpha state is that I want some feedback
This looks to be exactly what I needed for a fun project I’m working on with my FEZ Spider kit…will share the details once I have a prototype working.
A question…for lowest latency, would I be better off with TCP or UDP? I’m going to be firing messages quite rapidly, in all likelihood, and optimally, they should be 1.) processed in order, 2.) processed with minimal delay, 3.) not prone to message loss.
Your question is not easy to answer. TCP fit all your requirements and is not really slow. UDP has maybe lower latency but you have to implement some extra code for ordering and message loss detection.
Currently i haven’t done performance tests so i cannot say UDP is better in your case but I’ll test this this week.
It also depends on the data. Do you send small packages, a continuous stream,…
I plan some performance tests this week. Streaming a big file from an SD card.
And streaming a video from a WIFI camera -> WIFI Module -> FEZ Spider -> Ethernet Module -> PC :
Maybe i can tell you some performance data end of this week.
I use UDP for brodcasting sensor data or in my case for steering a robot. It doesn’t matter if a command arrives later or never.
Sounds like I will start off with TCP and see how I fare. The messages will be short strings, so I’ll start off using the bSendTCP_Click example from your client sample. Hopefully with the small payload, it’ll do OK perf-wise.
There’s a reason that it’s important not to miss messages, but that’ll have to wait until I get further along…want to keep this project a surprise for now.
One note of caution; the Spider Ethernet connection operates at 100 MbpS max, so don’t expect to see Gb throughput; even if you plug it into a Gb port on your switch.
Even with that, the responsiveness has been highly satisfactory in my testing.
I’m busy playing with the WiFi module (going to walk around the office scanning for rogue WAPs) ;D
I’ll post my results as soon as I’m happy with them.
Trying to integrate this now, not having a lot of luck so far, though it may be due to either my having forgotten some of the networking essentials I learned so long ago, or some of the corp policies on my laptop blocking stuff. I’m trying to connect to the tcpServer instance running on the Spider using a console app, but it’s throwing an exception saying the connection is refused.
Can you post some info on how you set your network up to test this? I’m currently trying to use a hub and cables between my laptop and the Spider to isolate the issue as much as possible.
FYI, the exact message I’m getting is “No connection could be made because the target machine actively refused it,” and I’m getting that both with the sample client as well as my console client.
I can successfully start up and test the LocalServer (local web server) on the ethernet module using the exact same port number as I’ve tried for the TcpServer instance, so I don’t think it’s a connectivity issue on my network. Any troubleshooting suggestions would be welcome.
I plugged in the spider in my home network no special config.
Do you have a local firewall on your lapttop?
Do you set the right IP adress, Subnet, and Gateway in the gadgateer programm and the Windows client?
I’m currently at work and have no hardware here but you can try something like this:
If you have a button mudule you can try to connect on the device without using any cable, switch,…
But connect a network cable!
void button_ButtonPressed(Button sender, Button.ButtonState state)
{
int yourPortNumber = 5000; // Set portnumber here if you dont use 5000
Debug.Print(ethernet.IsNetworkUp ? "Network is UP" : "Network is DOWN");
Debug.Print(ethernet.IsNetworkConnected ? "Network is Connected" : "Network is NOT Connected");
try
{
using (var s = new System.Net.Sockets.Socket(System.Net.Sockets.AddressFamily.InterNetwork, System.Net.Sockets.SocketType.Stream, System.Net.Sockets.ProtocolType.Tcp))
{
byte[] test = new byte[1];
byte[0] = 0;
IPEndPoint ep = new IPEndPoint(IPAddress.Parse(ethernet.NetworkSettings.IPAddress) ,yourPortNumber);
s.Connect(ep);
s.Send(test);
}
}catch(Exception ex)
{
Debug.Print(ex.Message); // Set Breakpoint here
}
}
This code is untested but it should work.
Set a breakpoint in the catch block and one where you handle the DataReceived event.
If the code work there is some “bug” in your network configuration.
I ended up simplifying and removing the GadgeteerNetworking stuff for now. Since the ethernet instance exposes the ability to set up a simple web server, and respond to requests on specific paths, I’m just setting up a series of paths for the particular commands I want to use, and calling them using an HttpWebRequest on the client side. Fewer dependencies, and it works fine with my network setup, which strongly suggests that there’s something different going on with the network code in GadgeteerNetworking.
Not sure whether or not I’ll run into issues with the order in which the commands arrive, but I’ll burn that bridge when I come to it.
@ Brett
Netmon…of course. Where were you at 3am when I was trying to remember the right tool for network troubleshooting?
Well, it all worked out in the end. I got the demo working at around 4pm today, which meant I was a little late for my presentation, but folks didn’t seem to mind given the awesomeness of the demo…but I’m going to have to keep it under wraps until the end of the month, or else Pete Brown will know what he’s up against for our co-presentation on Gadgeteer coming up in Baltimore on the 30th.
Thanks for the suggestions.
And @ Roman2, I will likely give your library another shot in the future, but I had to bail on it last night, since I only had a limited amount of time to get my demos put together for my user group talk this evening.