Re: UDP vs TCP
From: Jim Rodgers (noreply_at_today.com)
Date: 07/27/04
- Next message: Jim Rodgers: "Re: Anyone still speak english ??? re: Deployment of MSDE"
- Previous message: Paul Clement: "Re: cannot refresh Datarepeater"
- In reply to: kelly: "Re: UDP vs TCP"
- Next in thread: kelly: "Re: UDP vs TCP"
- Reply: kelly: "Re: UDP vs TCP"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 26 Jul 2004 22:52:36 -0400
Kelly,
If you could use TCP instead, you'd be far, far better off. Read on, and I
will totally convince you of that fact.
Basically, TCP -is- UDP with all the error checking, retransmission of lost
packets, and re-ordering of packet fragments added in. This is why it
exists. This is why FTP, HTTP, and most every other protocol are packed
into TCP data payloads. And you can transmit ANYTHING you like in TCP
packets.
TCP is referred to as a "Reliable" protocol because it takes care of the
transmission integrity for you. Why do you want to fool with that? Guys
like Martin, who have pre-existing protocols in their data streams, can dump
whatever they have into TCP with no fuss or worries about their pre-existing
protocols interacting with the TCP mechanisms. Send twelve CR's if you
like. Twelve CR's is what are received. This is a powerful feature of
reliable protocols. So-called "unreliable" protocols like UDP do not offer
any useful tradeoffs for all the extra work you have to do.
Remember, the difference between TCP and UDP is implemented in the operating
system! And it's "connection-oriented." Soon you'll discover the value
of -that- feature to your program's design. To add another analogy for you,
TCP communications are like phone calls: you get events to trigger your
code to begin the conversation, to monitor the connection integrity, etc.
Jim Carlock mentioned SLIP. Here's another great advantage for you to
enjoy. SLIP (and other point-to-point serial line protocols like PPP) is
written on top of TCP. And once again, the OS does it for you! In other
words, you need not (and often cannot) fool with the actual serial port.
Instead, you will likely have some kind of ActiveX control or whatever that
taps into the TCP/IP stack from the other side of the OS. Let the OS manage
the CRC's and the Stop Bits!
BTW, SLIP is more common in UNIX environments. PPP is how the MS Dialup
Networking ("DUN") works by default. I would try using DUN to configure the
PPP connection if this were a part of my application. If you communicate
with a private network, you may still co-mingle your private TCP packets in
the OS's TCP/IP stack. If you communicate with an entity over the PPP
connection, it can have a "private address" (like 10.5.7.14 or 168.0.1.112),
which the OS knows not to let out onto the Internet. IP routing is not
rocket science, but it can be confusing. You should get some help from a
friend or a newsgroup if you don't have the time to learn about it.
What I think you SHOULD be reading up on are the TCP/IP protocols. This is
great stuff! If you like coding CRC's, then you might enjoy coding
encryption for your data before dropping it into the TCP payload. Now it's
not only reliable, it's secure as well. And if you want to get out of that
work, try using HTTPS (secure web connections). Or maybe encrypting your
data into HTTP so you can fly through web servers and firewalls without
having to negotiate the security certificates required for HTTPS. You can
use HTTP and HTTPS over SLIP and PPP serial line connections.
If you simply have to see <SYN>, <STX> and <EOT> characters to be happy,
make or get a network sniffer and watch the TCP/IP protocols do their thing.
It's a riot! Really. You'll be talking in hex codes in no time. You can't
imagine how many different words engineers have learned spell with just the
letters A though F.
You can get HTTP connectivity in your applications using the Microsoft
Internet ActiveX controls, which are included in VB6. That's what I would
do if I were you. I'll bet you can get it to work without even fully
understanding the stuff under the TCP/IP hood, as it were. When I did this
for the first time, little did I know it would take me so far into Networks
System Engineering. Now I'm doing TCP, HTTP, SNMP, SMTP, ICMP, broadband
testing, UNIX testing, and more.
Good luck and Enjoy!
James W. (Jim) Rodgers, P.E.
Senior Consultant
General Consulting Engineers, LLC
Atlanta, GA
"Charter Member" MCSD
"kelly" <kelly@discussions.microsoft.com> wrote in message
news:64A33AEA-47F8-4BBC-9878-87CF411C0F0A@microsoft.com...
> 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!
> > >
> >
> >
- Next message: Jim Rodgers: "Re: Anyone still speak english ??? re: Deployment of MSDE"
- Previous message: Paul Clement: "Re: cannot refresh Datarepeater"
- In reply to: kelly: "Re: UDP vs TCP"
- Next in thread: kelly: "Re: UDP vs TCP"
- Reply: kelly: "Re: UDP vs TCP"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
