Client/Server (Master/Slave) or mixed mode?

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

Reply to
ElderUberGeek
Loading thread data ...

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äsenz im Netz GITmbH
 Click to see the full signature
Reply to
Kurt Harders

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 
 Click to see the full signature
Reply to
CBFalconer

Why would UDP be better? In what way?

Reply to
ElderUberGeek

- 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

Reply to
Gerard

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.