kbhit() equivalent in Windows MFC (VS 6.0)

Jim:

I'm just blogging this because it took me too long to find it... I needed to be able to break out of a loop by pressing a key; the example below uses the escape key. This block is within a larger loop. It samples the keyboard every 100 operations as bCount is incremented:

if(!(bCount%100)){

keyData = GetAsyncKeyState(VK_ESCAPE); //ESC KEY
if(keyData) {
break;
}
}

See the following references:

http://msdn2.microsoft.com/en-us/library/ms646293.aspx
http://msdn2.microsoft.com/en-us/library/ms645540(VS.85).aspx

UDP Checksums in Embedded, Linux, and Windows Systems

Jim:


Background:

I'm currently developing embedded and application software in order to stream large quantities of data between an embedded system (Avnet Fx-12 Mini Module) and a Host PC System. The embedded software is based on a Xilinx 9.1 Gigabit Ethernet reference design. This reference design sends and receives raw Ethernet frames by various methods - polled mode, interrupt driven, and scatter/gather DMA; but to be usable with PCs at the application layer, it must implement a standard protocol. Due to speed and resource requirements, I chose UDP.

The User Datagram Protocol (UDP) is an "open loop", session-less means for networked device communication. UDP is open loop in the sense that it does not guarantee that the data being sent will ever arrive at its destination; using UDP is like sending junk mail via the postal system. One "assumes" that the letter will arrive at its destination; if not, the sender will not be notified, and the information will be discarded.

UDP is session-less in the sense that there is no interaction between the sender and receiver to ensure the integrity of the communication link as there is with TCP. An analogy here would be a phone call between two people.... The sender dials the recipient's number; a conversation only ensues if the recipient answers the phone; both parties (typically) decide when to terminate the conversation.

The relative simplicity of the UDP protocol would make it an ideal choice for high-speed data transfer in low-end embedded systems - if it weren't for the UDP checksum calculation requirement.

The Ethernet, IP, and UDP Layers

There are too many details to describe here; but in summary:

• Each UDP packet is encapsulated first by Internet Protocol (IP) information, and then by Ethernet information.
  
• At each of these layers, there is a means to determine the integrity of the data being transmitted:

• At the Ethernet Frame(lowest) layer, the hardware ensures data integrity by validating (or generating) a checksum on the entire Ethernet frame.
• At the IP layer, the sender must calculate the checksum of the IP header portion of the data being transmitted. Because the data in this layer is small, the processing overhead is not excessive.
  
• At the UDP layer, things get interesting.

UDP Packet Processing

In theory, every UDP packet sent by an embedded system contains a checksum on the UDP portion of the data in the packet. This checksum is then used by the recipient to validate the integrity of the UDP data in the packet - the UDP payload.

In practice, the UDP checksum is calculated in two ways. In higher-end systems, special hardware and drivers offload the UDP payload checksum calculation, and inserts the checksum value into the UDP packet. But in lower-end embedded systems, the checksum must be calculated in software. This adds a huge processing burden to the system. It can turn a data "stream" from an embedded system into a trickle.


Eliminating UDP Checksum Calculations

What happens if we don't perform the checksum calculation? RFC 1122 states the following:

  4.1.3.4  UDP Checksums

       A host MUST implement the facility to generate and validate
       UDP checksums.  An application MAY optionally be able to
       control whether a UDP checksum will be generated, but it
       MUST default to checksumming on.

       If a UDP datagram is received with a checksum that is non-
       zero and invalid, UDP MUST silently discard the datagram.
       An application MAY optionally be able to control whether UDP
       datagrams without checksums should be discarded or passed to
       the application.

So, as long as I set the UDP checksum field to zero, everything should be fine, right? Here's what I discovered in practice:

1. I typically use Ethereal to debug network traffic; with UDP checksums disabled, Ethereal showed all traffic being transmitted & received as expected. This applied in Linux (Fedora 8 via Wireshark), and Windows XP.
2. In Windows XP, the checksum-less UDP packets vanished. Surprise. Packet sniffers use their own stacks. Windows elects to "silently discard" UDP packets with checksums set to zero. Try finding this documented somewhere.
3. In Linux (Fedora 8, at least) the checksum-less UDP packets are accessible at the application layer.

Conclusion

Zero-checksum UDP packets are ideal for streaming large quantities of data from embedded systems to Linux Hosts. Windows XP cannot be used to receive this data stream. If there is a way to disable the "silently discard" behavior of the Win32 stack, I have yet to find it.