Re: UDP vs TCP

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: kelly (kelly_at_discussions.microsoft.com)
Date: 07/23/04 

Date: Fri, 23 Jul 2004 12:03:01 -0700

Thanks, Martin!

I am using UDP, therefore I need to do CRC check myself.

As for using <STX> and <CR> to wrap the message, what if somewhere inside your message one or both of these two values show up? <CR> has a value of 13 (if I remember correctly). What if one of the bytes in my message has a value of 13? Then I would mistaken it as the end of the message (which in fact is just one of the bytes of the message content). That approach requires "trial and error" to find out if the <CR> you find in the message is part of the message content or is the end of the message.

So happen you mentioned serial communications, I am looking for some information on that as well. I am quite lost with that. If two computers are connected via serial comm, it has nothing to do with UDP or TCP, correct?

Thanks a lot!

"Martin" wrote:

> FWIW, here's what I do in your situation: frame your messages with a
> single character at each end (I use <STX> and <CR>). I don't bother
> with the CRC - it's my understanding that TCP will take care of that
> for me. On the receive side, buffer your incoming data (looking at
> each individual character as it comes in) until you spot the <CR>. At
> that point, you know you have a complete message. Then search the
> buffer for the <STX>. Now you know where your message is, extract it
> and do some quality checks (correct length?). If it passes, go with
> it.
>
> I used this approach years ago with serial communications; as I've
> moved over to TCP/IP, I've found that the same concept applies and is
> still useful.
>
> HTH
>
> On Fri, 23 Jul 2004 11:02:01 -0700, "kelly"
> <kelly@discussions.microsoft.com> wrote:
>
> >Thanks a lot for your detailed info.
> >
> >I understand that UDP doesn't guarantee proper delivery of the message, that's why we have to add the CRC to the message to check if the message received is correct. Here's what I don't understand:
> >
> >For example, I have two messages:
> >"3XYZ5"
> >"4ABCD9"
> >in which:
> >"3" is the length of the first message content, "XYZ" is the first message content, "5" is the CRC of the first message.
> >"4" is the length of the second message content, "ABCD" is the second message content, "9" is the CRC of the second message.
> >
> >If I receive the two messages (concatenated) in one single receive event, and if the first message was screwed up, I might receive something like:
> >
> >"3XZ54ABCD9"
> >
> >which is incorrect ("Y" is missing in the first message). When I parse this received message, I would interpret:
> >
> >"3XZ54" as the first message (because length is "3")
> >"ABCD9....." as the second message (because length is "A")
> >
> >The CRC of the first message indicates that it's delivered improperly. Same for the second one. HOWEVER, the fact is, only the first message was screwed up, the second message was actually delivered properly.
> >
> >Is the above case possible? If EACH receive event only receives ONE message, then the above scenario wouldn't exist. The first mesage would have been discarded after CRC check, and the second message would have been kept. If there is a chance that the messages are concatenated (or broken up), then the screwed up message might impact the OK messages.
> >
> >Could anybody clarify this? THanks so much!
> >
>
>

Relevant Pages

  • Re: UDP vs TCP
    ... "TCP/IP is typically transported across a serial line using either the ... I am using UDP, therefore I need to do CRC check myself. ... >>which is incorrect ("Y" is missing in the first message). ...
    (microsoft.public.vb.enterprise)
  • Re: CRC checksum algorithm
    ... working on an older PLC interafce to OPC. ... I will have to write a CRC algoritham and since this interface is ... > Author of Visual Basic Programmer's Guide to Serial Communications, ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Opinions on 16-bit checksums.
    ... >> possibly result in an unchanged CRC checksum. ... > There are two big reasons CRCs are used in serial communications: ... algorithms that consider the order of the data as well as the value - a ...
    (comp.arch.embedded)