Don’t know if it’s allowed to answer this kind of questions here, so if it’s not the case, mods feel free to remove it.
So, I’m planning on transmitting data between a PC and a Fez Cobra over TCP. What would be the best way to construct the messages. I know i can send plain text, but I’m sure there’s a more elegant and robust way to do this. Can you point me to some resources or provide more details?
PC will ask for data at specified interval, and cobra will need to send events as they arrive on the IO pins. Guess I also want some sort of buffer on the Cobra. When I’m updating my PC app, the cobra should buffer/queue the messages and send them again when my app is online again. Need to investigate how i can accomplish that.
There are several ways to handle what you want to do - it just depends on how fancy you want to get. Like you said, you can send simple fixed-width strings across the socket if it suits your needs. Using XML is also an option, and might be a good one especially if you’re going to send multiple messages in batches to the PC. There’s also DPWS, but that’s probably overkill for what you want to do. There is no one “right” way to do it - just whatever makes sense for your app. XML or delimited strings are probably the way to go if you have simple messages to send.
If you need to support communication initiated from both the Cobra and the PC to each other, you’ll need to set up a TCP socket listener on both of them to wait for incoming connection requests. The .NET code for this should be very similar for the full .NET framework and the Micro Framework.
After some googling i found this article: [url]http://www.eggheadcafe.com/articles/20021125.asp[/url], while MSMQ would solve the buffer/queue part (I could easily setup a queue on the pc hosting my app), it is not available in the Microframework. Is there an alternative way?
You’ll have to roll your own message queueing code. Here’s something I might do for your queueing issue on the Cobra. I don’t know the exact requirements of your app, but this would be a very basic approach.
When the Cobra generates a message that needs to be sent to the PC, I would persist that message to local storage on the SD card (either one message per file or several messages in a file). I would then have a separate thread running that periodically checked the file(s) for outstanding messages that need to be sent, send them to the remote PC if a connection is available, then delete the local messages. Of course you would need to make sure to handle concurrency issues on the files so that both processes weren’t trying to write to the files at the same time. This would essentially be a very simple version of MSMQ. Hope that helps?
String incomingMessage; // created from inbound buffer '\r' stripped
// seperators to seperate parts of message
char[] seperators = new char[] {','};
// split message into parts
String[] parts = incomingMessage.Split(seperators);
String receivedCommand = parts[0]; // contains cmdx
int variable1= parts[1].ToString();
Strings are easy to use and human-read (debug) but they take a lot of processing from FEZ. Do not use strings if you are planning on transferring thousands or arguments back and forth.
That won’t be the case (only strings of max 100 characters every now and then)
Sorry if this sounds as a dumb question, but i never did this kind of stuff.
In order to send AND receive TCP messages between pc and Fez Cobra, I need a TCPClient and a TCPListener on both pc and cobra, right?
[quote]In order to send AND receive TCP messages between pc and Fez Cobra, I need a TCPClient and a TCPListener on both pc and cobra, right?
[/quote]
I think Gus and I differ on this question. :’(
A TCPClient initiates a call to a TCPListener. The TCPListener, which had an outstanding Accept method, returns a new socket through which communications can be done with the TCPClient socket. The communications can go both ways over the sockets.
This architecture is called client/server.
Only the side that receives an incoming connection needs a TCPListener. In most applications, this is only one of the sides.
So, if you application has a program on a PC which needs to get to a FEZ every few minutes to pick up data, then the PC would only need a client and the FEZ would need a listener.
I guess you could have an application where both sides need to initiate the session/connection, and in this case, both sides would need a listener and a client.
allow me to explain a bit more what i’m looking for.
The Fez Cobra will have a bunch of sensors attached. Some sensors are responsible to count pulses, other sensors will measure temperature, and other sensors will catch events like when a door opens or closes.
What I would like to do is to sent the counters and temp sensor values when requested by the pc. Regarding the events happening on the Cobra, they need to be send to the pc (without the pc asking for it).
If you want to sound nuts you will have to try harder.
As you described, another way to handle the problem is to have all calls initiated from the Cobra. The sensors on a schedule, and the events on demand.
If this works for the application it is a simpler solution.
I have to go for TcpListeners on both sides because the pc will have to send commands to the Cobra for example to turn on/off a light. Will be a challenging design :