- UDP is simpler to implement (no timers, windows etc.).
- It is also quicker to setup an UDP connection then a TCP connection.

But you don't have any acknowledgment with UDP (so no resend at datagram 
lost at this level). If you use UDP your application must do this.

Regards

ElderUberGeek wrote:
> 
> I don't see why you say my question makes no sense. I am quoting your
> last post:
> 
> "Maybe you want to reconsider using TDP.  UDP may be adequate, and
> certainly simpler to implement."
> 
> So, you yourself say that UDP may be adequate (i.e. I understand this
> as "better") - so I am asking why.

I am sure I didn't say that in isolation.  As it is, I have no idea
what it is all about.  All I can see here is the current article,
anything old is marked read and long gone, or may never even have
arrived here.  I read, and possibly answer, hundreds of articles
daily.  That is why context (and proper attribution) is so
important.  Every article needs to stand entirely by itself.  The
following may help you understand the system.

http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.greenend.org.uk/rjk/2000/06/14/quoting.html
http://www.i-hate-computers.demon.co.uk/
http://web.ukonline.co.uk/g.mccaughan/g/remarks/uquote.html

> 
> By the way, I am fully aware of Usenet and news readers.....

You show no evidence of that.  If you must use google, I suggest
you back up to my original reply and generate your own reply to
that, using the methods described below in my sig.  Then this
thread might become understandable.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

I don't see why you say my question makes no sense. I am quoting your
last post:

"Maybe you want to reconsider using TDP.  UDP may be adequate, and
certainly simpler to implement."

So, you yourself say that UDP may be adequate (i.e. I understand this
as "better") - so I am asking why.

Thanks

By the way, I am fully aware of Usenet and news readers.....

ElderUberGeek wrote:
> 
> Why would UDP be better? In what way?

For what?  Your question makes no sense without context.  See my
sig. below.  Make sure you read the referenced URL.

Usenet is much different from the view googlers see on google. 
Most users use real newsreaders.  Usenet has been active for about
30 years, and has some well settled protocols.  The google
interface is an excresence.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

Why would UDP be better? In what way?

ElderUberGeek wrote:
> 
> I have an embedded box that talks to a PC (a controller for an
> industrial device which is used to detect its state and also
> control it). I am using TCP (Ethernet).
>
> The way I understand, there are two ways to architect this:
> 1. Either the box is always the Client and the PC is always the
> Server, and then the only way the box will respond it when it is
> polled 2. Or both can act as both Client as well as Server
> 
> What are the design considerations for each mode? Which is better?

Maybe you want to reconsider using TDP.  UDP may be adequate, and
certainly simpler to implement.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

Hi,

ElderUberGeek wrote:

> 1. Either the box is always the Client and the PC is always the
> Server, and then the only way the box will respond it when it is
> polled 2. Or both can act as both Client as well as Server

This difference is not so big. Just decide who is initiating the
connection. If the hardware box is normally powered and the PC is not
allways connected, then make the hardware box the server and have the
PC connect to it. If its the other way round, and the PC remains
powered, make PC have the server socket (listen) and have the hardware
box connecting to it.
After the connection is established the client usally contacts the
server. If a two way communication is required, where both sides are
allowd to send, you establish a second connection, as its done e.g. in
ftp. Then you have both sides waiting on a port.

Regards, Kurt
-- 
Kurt Harders
PiN -Pr&#4294967295;senz im Netz GITmbH
mailto:news@kurt-harders.de
http://www.pin-gmbh.com

I have an embedded box that talks to a PC (a controller for an
industrial device which is used to detect its state and also control
it). I am using TCP (Ethernet).
The way I understand, there are two ways to architect this:
1. Either the box is always the Client and the PC is always the Server,
and then the only way the box will respond it when it is polled
2. Or both can act as both Client as well as Server

What are the design considerations for each mode? Which is better?

Thanks