I have a project in mind for connecting multiple NETMF devices together over Ethernet/WiFi that allows either the PC or any of the devices with ad-hoc WiFi available to act as the main server issuing commands and controlling data flow.
My original idea was to open a UDP socket on a specific port and let command set logic determine the roll and identity of any newly joining device. For example if a device can act as host it will first send a message RequestHost and if another device is already acting as server it will respond with a deny command. Otherwise the device will assume the host role. Similar logic goes into assigning device IDs where the device sends a RequestJoin and the server responds with OK/Deny and the ID if appropriate.
A key issue here is I will have devices running 4.1 and other devices running 4.2. My rather simple attempt of bind to UDP port and start broadcasting a predefined device ID seems to fail miserably.
Socket.Send blows up on 4.1 and doing a SendTo with either the Remote or Local EndPoint doesn’t seem to get me anywhere either. 4.2 sends without exception but I can’t be sure it’s getting through at the moment bc the only device I have w/ WiFi is 4.1 (uses OLD WiFi so I can’t use 4.2 as it’s been removed from that version) and I only have a single Ethernet port available to plug a 4.2 device into.
Ideas, suggestions, wonderful working pieces of code?
Yup I’ve got several things planned. Each device can list off its capabilities to the others and I have some 60+ commands on the list so far including:
File IO operations
Running SBASIC (and returning results)
Shelling a NETMF application
Getting/Setting RAM data
Running SQLite (and returning records/results)
Managing service exposed pins (Read/Write/SetPulse)
Send/Broadcast message
Join/Leave
I’ll definitely send you something this weekend. Best thing is to have more than one NETMF device with networking but you can also work it with a single device and one or more PCs. Here’s the checklist for this weekend’s release to you:
First server capable (user settings per device) device to boot takes server status
New server requests are refused (device requesting to be server will instead request to be client)
Devices joining are assigned ID #s and given a list of all currently connected devices
All currently connected devices get a message about new devices
Servers can be forced to stop serving, a new device will take over automatically
A client can be told to take over as server (client can refuse if not set to allow server mode)