Main Site Documentation

Fast and Easy way to communicate via UDP and TCP


#1

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 :slight_smile:

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;                    
            }
        }


UDp Sample


 private void udpServer_DataReceived(System.Net.EndPoint sender, GTM.Module.NetworkModule.UDPServer.DataReceiveEventArgs e)
        {
           
            var receivedData = e.Data;
            Log(new string(System.Text.Encoding.UTF8.GetChars(receivedData)));
            
        }

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 :slight_smile:

Sourcecode and Sample is available at codeplex: http://gadgeteernetworking.codeplex.com


#2

Very cool and thanks for sharing.


#3

@ Roman2

Your timing is absolutely PERFECT!

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.

Thanks for sharing this!


#4

Tanks devhammer :slight_smile:

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 ::slight_smile:

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.


#5

@ Roman2

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. :slight_smile:


#6

Also thanx for the posting!

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.


#7

@ devhammer and and all the others have the code downloaded. DELETE IT

I found a very cool way to implement my Project as an Extension method. So it’s not longer nessesary to modify the gadgeteer sourcecode ;D

Now you only need to reference the two assemblies and code your project.


#8

@ Roman2

Great to hear, I had not yet had a chance to download and integrate the code, so no extra work for me, yay! :slight_smile:


#9

@ Roman2

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.

Thanks!


#10

@ Roman2

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.

Thanks!


#11

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.


#12

netmon. Watch the traffic :slight_smile:


#13

@ Roman2

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? :wink:


#14

I was in Australia - probably at work :slight_smile:


#15

@ Brett

LOL!

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. :slight_smile:

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.


#16

Hi Roman2, any progress on this project, it’s quite interesting!. I saw it on codeplex but the last update is from 9 december.


#17

@ patrick9

You might find this project helpful in terms of TCP, at least:

I’m using Marco’s code in my IR Helicopter control project, which allows my IR controller to be controlled over the network.

Definitely beat the heck out of my attempt to build out the socket code myself. :slight_smile:


#18

Thx, i’ll give it a try this weekend!