Re: messaging protocol - how about this as a design

Angus wrote:
Hello

I am using tcp and am designing a protocol for sending and receiving
data.

Can anyone please comment on my design

Your design is very naive. Please look at existing textual protocols like
SMTP, POP, IMAP, FTP and HTTP, read about their problems and limitations and
then try to resuse the good parts and avoid the bad.
Unless you are willing to devote large amount of time to this you will be
better off using some existing protocol. The already mentioned SOAP should
be a good choice (see gSOAP library for portable C with little ++
implementation)

--
Eugene


.

Relevant Pages

  • Re: How to deal with full-duplex communication?
    ... TCP/IP itself will not and cannot "lose" messages. ... is an error in your protocol. ... completely asynchronously as part of the design. ... At the level of socket io, you cannot really coordinate sending and receiving, ...
    (microsoft.public.vc.mfc)
  • 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)