Comms buffer issue

[Tisme]

I have an application that sends piles of data down the com line to an external device, and for the most part it works fine.
The external device can at any time send a CTRL_S message to the application that tells it to suspend sending data until a CTRL_Q is sent.
The app will in fact stop sending data until it receives the CTRL_Q signal. No new data is sent to the i/o port.
But, there can (and invariably is) data still stored in the i/o device that will be sent down the line to the external device. Is there any way that upon receiving the CTRL_S signature, that my app can force the hardware to not send what's in it's buffer.
(The problem arises because the external device sends a CTRL_S when it's buffer is getting full to halt the data stream. Any data received after it sends the CTRL_S is either discarded, or causes bad things on the external device).

The routine responsible for sending the data:

BOOL ZComm::WriteFile(unsigned char ch)
{
m_nWritingNumber ++ ;
if ( !::WriteFile(h_File,&ch,1,m_pdw,&ov_Write))
{
DWORD dw;
if (GetLastError() == ERROR_IO_PENDING)
return GetOverlappedResult(h_File, // Handle to COMM port
&ov_Write,// Overlapped structure
&dw, // Stores number of bytes sent
TRUE); // Wait flag
return FALSE;
}
return TRUE;
}

I also use the functions:
ClearCommError
SetCommState
etc
to set up Comm port information.

Thanks for any advice, or pointers.

[RNEELY]

Sounds like your app asynchronously spews a data to a device, but that device expects to be able to synchronously stop and start the data.

Potential options from the simplest to most complex:

1. Implement SLIP across your serial link - http://www.ietf.org/rfc/rfc1055.txt . SLIP uses two END characters to help remove line noise. There is sample C code in this RFC. Perhaps you could expand on the idea.

2. Implement a proprietary, application-level, byte-oriented, asynchronous, end-to-end-acknowledged protocol with retransmit. The idea is you frame your packets with characters such as STX and ETX. You only transmit the next packet after you have received an ACK for the previous packet. One packet is held for retransmission in the event an ACK is not received from the device in time. The device would throw away data that is not framed. Character codes are available @ http://www.ascii.cl/index.htm.

3. Implement PPP across your serial link - http://www.ietf.org/rfc/rfc1661.txt to frame the protocol in 2.

Good luck.
// Ron