Re: How to deal with full-duplex communication?

Note that TCP/IP guarantees that everything that is sent is received in the order it was
sent. Beyond that, any complex asynchronous protocols have to be designed to be
resilient, as already pointed out. If A sends a message to B, and the only thing B can do
is ACK/NAK it before A sends another message, there should be no problem. But if you have
messages sent like

A1 A2 A3 B2 B1 B3

makes perfect sense because the message A1 may require more computing on the other side
than A2, so B2, the response to A2, will be sent by B before it completes the processing
of A1 and sends the B1 response.

TCP/IP itself will not and cannot "lose" messages. If you are seeing message lossage, it
is an error in your protocol. In fact, protocol design can be very complex in a
completely asynchronous system where the messages interact; if the messages are
independent, however, with their responses, then each side has to be completely driven by
what is coming back, completely asynchronously as part of the design.

Overall, it sounds like you have a fundamental design error in your protocol, because I've
done a lot of asynchronous TCP/IP with complex protocols and the underlying mechanism
works perfectly. Any errors you are seeing are almost certainly a problem with your
design.
joe

On Sat, 27 May 2006 08:03:01 +1000, Ian Semmel <isemmelNOJUNK@xxxxxxxxxxxxxxxxxxxxxxx>
wrote:

The 'Async' part of the class name is the key to this sort of problem.

At the level of socket io, you cannot really coordinate sending and receiving,
as this just happens at any old time when windows feels like it.

As messages are assembled at the socket level (which I always put in a separate
thread), you should post complete messages to a higher level (eg the main gui
thread) which can then work out the logic of what to do next.

fadics wrote:
Thank you.

The return receipt I use is the size of all received data. So I can know
which message has been received. But the problem is still there. When both
side send and receive data at same time, the return receipts can not be
sent. Because they don't know whether the last message has been received. If
I send the return receipt immediately regardless of the receiving of other
side, the return receipt may be lost. By the way, I use TCP with
CAsyncSocket. But the lost is still on. I add watch to the OnReceive
function. The return receipt was not received.

Thank you anyway.

"Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> ????
news:uYxn9e$fGHA.356@xxxxxxxxxxxxxxxxxxxxxxx

fadics wrote:

I use CAsyncSocket class.
When A receives a packet, it sends a return receipt to B. B does the

same.

When A and B send a packet at the same time, they receive the receipt of
previous packet. So they wait the last receipt at the same time. The
communication breaks. How to solve this problem.

Thank you for any answer. A sample is welcome more.

Your protocol logic must be prepared to process whatever it receives.
It cannot assume that the next message must be a return receipt. If
your return receipts contain a serial number of the message being
acknowledged then you can maintain a list of pending receipts. (It is
possible you will receive several messages before receiving a receipt.)

--
Scott McPhillips [VC++ MVP]




Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: messaging protocol - how about this as a design
    ... I am using tcp and am designing a protocol for sending and receiving ... Your design is very naive. ...
    (microsoft.public.win32.programmer.networks)
  • Re: lines of code?
    ... It sounds like you're saying that I should use multiple threads ... dont really get anything more than a single-threaded design would. ... a TCP-based protocol cannot, afaik, be "streaming". ... involving multiple levels of recursion? ...
    (comp.programming)
  • Re: lines of code?
    ... It sounds like you're saying that I should use multiple threads ... dont really get anything more than a single-threaded design would. ... a TCP-based protocol cannot, afaik, be "streaming". ... involving multiple levels of recursion? ...
    (comp.lang.java.programmer)
  • Re: DoModal isnt reentrant but failure mode could be improved
    ... >XP are masking the interrupt for more than 1ms, it's not going to matter how ... >suppose we just proceeded to send the next command to the device without ... I didn't design the protocol, by the way; ... protocols is a serious design problem. ...
    (microsoft.public.vc.mfc)
  • Re: Shared Memory for Application/Communication decoupling
    ... If the device was busy it only answered to special commands which where handled in an interrupt. ... The big problems are that you have problems with consistency and in my opinion it should be done like I scratched below (at least if requirements allow and what I learned from working with protocol stacks). ... And you get your temporal decoupling for free, or more specifically as a key part of the design. ... It is not possible that the communication task runs only when the currently calculated data has become stable because the calculation takes to long. ...
    (comp.arch.embedded)