Recv() socket question

[Armor Gnome]

Beginner UDP question here.

I need to write some code so that a networked node can call a socket and send() a few packets to dcerouter.  This is dirty and primarily to give me something to build on and improve once it's operational.  Niceties like waiting for ACK, ipv6, etc, I can add later if I stay with this hardware.

Question:  As I read C/C++ tutorials on socket transmission everything seems to imply I need to write code on both client and server, one to send() and one to recv().  Is this necessary on lmce or is dcerouter ready to accept a packet being thrown at it?

Question2:  Would a close function be necessary?  It's against almost everything I have read but if my intention is to constantly watch for incoming data from a connected node, wouldn't I want the socket open already?



*device info if it helps.  I am using a networked computer and keytronics board to function as a contact switch monitor.  A normally open circuit (doorbell button would momentarily close) wires to a keyboard input, [8].  The connected PC will understand that if keyboard input=[8] then send (?) data to 192.168.80.1/60000.  This remote PC will run headless and will eventually have more switches wired to the keytronics board.  Anything I can wire as normally open with closed only when something happens can send a unique data package. I will need to be creative in how I close contacts, like a window sensor that when the window is down, a magnet holds a switch open so when the window opens the circuit closes and a key press is sent to the computer.  Switches are < $0.50 each retail and a keyboard has 102 keys.  Compared to any other doorbell/sensor system I think this warrants some experimenting and code learning on my part.

[Armor Gnome]

I found some great information on the wiki about GSD creation and serialized class, I have stepped back to review my process for creating this device with that new information and will update once I have my module operational and attempting to talk to DCE.  I can't seem to get this hardware to boot anything other than windows ce 4.2 so will be spending some time in ancient dev environments for a while.   

[tschak909]

UDP can not be done by the GSD, GSD is designed for RS232 and TCP communications, only.

So for C++, you'll need to use some bits to do socket communications. Since this is UDP, you will need to do all of your own socket communications, as the socket libraries in libDCE do not have any provision for this (TCP only)...

For an example of how to do this, look at the code for src/VistaICM2, and look at the CCP thread, it recieves UDP packets sent by the security panel for further decoding and processing.

-Thom

[Armor Gnome]

Thanks Thom,

Because I am writing this myself(ourselves technically, this project finally has the roommate looking at code) I assume that as long as the device can understand and get the libraries then I can send these packets with whichever protocol we choose, and can figure out.  UDP when I was researching methods for remote writes seemed the best alternative, I am not sold on it at all.

- Reading over wiki articles has shown me the benefit of doing this correctly, error correction and the ability to poll state back through the socket will be nice

- Reviewing a few more TCP using templates and wiki articles before I go back to the device and look at my options

- This all started with attempting to direct wire a contact switch to my core (par or ser), after study though I felt it was cleaner to have this 0.02w device sitting on the network and watching various circuits.  If it sees something it can tell DCE.

- We had simple logging of events going on a (precise) test machine where keystrokes where logged with time and "doorbell rung" on the local machine. This was done with modules though and not our own code. 

- To add features to this device down the road I hope to take advantage of its parallel, serial, and usb-to-http://numato.com/8-channel-usb-gpio-module

I appreciate your time.  I know you are not a fan of duck tape devices but it's what I have available to learn with and with each project I am learning a lot more about lmce and coding.  Another 2 dozen walking coffee pot w/ voicemail builds and I may be able to actually help with some of the (3 million?) lines of LMCE code.