network design

[RedLars]

What would be a good solution for the following scenario? I have one
server and multiple client application running on different computers
connected by Ethernet. Internal state changes in the server needs to
be communicated to the client and user operations performed on the
client need to be sent to the server. Sort of a peer-to-peer
communications model where each party can start a communication
session. A service would also be implemented on the server that pings
the clients every x seconds. Creating a new tcp socket connection for
each transaction would be slow. Creating one tcp socket connection
from server to client would only handle transaction started by the
server, right? Or can both parties send at any given time on one tcp
socket? What happens if they send at the same time? So I would have to
have two connections between a server and client, one for transactions
started by server and one for transactions started by the client.
However this would lead to having two sockets pr client, so if I had
40 clients that would be 80 sockets. Is this a concern? Using Udp
would also be an option but that requires some sort of acknowledgement
system. Thoughts?

 

[Peter Duniho]

What would be a good solution for the following scenario? I have one
server and multiple client application running on different computers
connected by Ethernet. Internal state changes in the server needs to
be communicated to the client and user operations performed on the
client need to be sent to the server. Sort of a peer-to-peer
communications model where each party can start a communication
session.

"Peer-to-peer" implies each endpoint is an equal partner. What you've
described, with a single centralized manager of the entire operation (i.e.
the "server"), is "server/client".

A service would also be implemented on the server that pings
the clients every x seconds. Creating a new tcp socket connection for
each transaction would be slow. Creating one tcp socket connection
from server to client would only handle transaction started by the
server, right?
Wrong.

Or can both parties send at any given time on one tcp
socket? What happens if they send at the same time?

Sockets are bidirectional. Simultaneous communications in both directions
works fine, at least as far as the socket is concerned. In your
application, you'll of course need some logic for organizing the
back-and-forth. But in the simplest applications, this is simply a matter
of only dealing with sending or receiving at any given moment (data will
be buffered...your application doesn't have to be ready at the exact
moment data has been sent to it).

Even in more complicated applications, it should not be all that hard in
most cases. The main thing would be to make sure that at a given
endpoint, you only ever send a complete sequence of bytes before starting
another one. So, for example, if you've got some kind of timer-based ping
logic, as well as some receive/reply logic, your ping needs to be
synchronized with the receive/reply so that it doesn't try to send the
ping in the middle of the reply being sent to the client. There are a
variety of strategies you can use, none of them too terribly bewildering.

So I would have to
have two connections between a server and client, one for transactions
started by server and one for transactions started by the client.
However this would lead to having two sockets pr client, so if I had
40 clients that would be 80 sockets. Is this a concern?

You don't need two sockets per client. But regardless, 40-80 sockets is a
very small number. High-performance server applications can have tens or
hundreds of thousands of open connections, perhaps even more.

Using Udp
would also be an option but that requires some sort of acknowledgement
system. Thoughts?

If you need reliable communications, use TCP. You can reimplement
reliability in UDP, but it's almost never the right thing to do.

Pete

 

[Mr. Arnold]

What would be a good solution for the following scenario? I have one
server and multiple client application running on different computers
connected by Ethernet. Internal state changes in the server needs to
be communicated to the client and user operations performed on the
client need to be sent to the server. Sort of a peer-to-peer
communications model where each party can start a communication
session. A service would also be implemented on the server that pings
the clients every x seconds. Creating a new tcp socket connection for
each transaction would be slow. Creating one tcp socket connection
from server to client would only handle transaction started by the
server, right? Or can both parties send at any given time on one tcp
socket? What happens if they send at the same time? So I would have to
have two connections between a server and client, one for transactions
started by server and one for transactions started by the client.
However this would lead to having two sockets pr client, so if I had
40 clients that would be 80 sockets. Is this a concern? Using Udp
would also be an option but that requires some sort of acknowledgement
system. Thoughts?

Windows Communication Foundation service on server with WCF clients over
TCP/IP consuming the WCF service.


__________ Information from ESET NOD32 Antivirus, version of virus signature database 4331 (20090813) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[RedLars]

"Peer-to-peer" implies each endpoint is an equal partner. What you've
described, with a single centralized manager of the entire operation (i.e.
the "server"), is "server/client".

The solution is a server\client from a logical point of view - the
server computer handles
the logic and the client present the information. However, from the
network
communicational point of view each endpoint should be able to
send a message to another endpoint at any given time.

If a user clicks on a button in the client application "DoWork" then a
message
is sent to the server with this information. In the same way, if a
server state
changes this might trigger the server to send a message to the
clients. So both client
and sever can send a request. My understanding of "client\server" is
that only the client
sends a request to the server and gets a respond.

Sockets are bidirectional. Simultaneous communications in both directions
works fine, at least as far as the socket is concerned. In your
application, you'll of course need some logic for organizing the
back-and-forth. But in the simplest applications, this is simply a matter
of only dealing with sending or receiving at any given moment (data will
be buffered...your application doesn't have to be ready at the exact
moment data has been sent to it).

That is good to know. Thanks.

Even in more complicated applications, it should not be all that hard in
most cases. The main thing would be to make sure that at a given
endpoint, you only ever send a complete sequence of bytes before starting
another one. So, for example, if you've got some kind of timer-based ping
logic, as well as some receive/reply logic, your ping needs to be
synchronized with the receive/reply so that it doesn't try to send the
ping in the middle of the reply being sent to the client. There are a
variety of strategies you can use, none of them too terribly bewildering.

That makes sense.

 

[RedLars]

Windows Communication Foundation service on server with WCF clients over
TCP/IP consuming the WCF service.

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4331 (20090813) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

We cannot use WCF for this solution.

 

[Peter Duniho]

[...] My understanding of "client\server" is that only the client
sends a request to the server and gets a respond.

That's not a typical usage of "client/server". For example, unless you're
using passive mode, the FTP protocol allows the server to initiate
communications to the client, but people aren't generally calling FTP a
"peer-to-peer" protocol.

You can use that definition if you like, but do be aware that it will
impede your communication with others. In general, "peer-to-peer"
actually means that either endpoint can initiate the original connection,
while "client/server" means that there's a single endpoint that sits and
waits for clients to connect, and the client are always the one to
initiate the original connection.

I agree that in most "client/server" protocols, the server only ever sends
data to the client in response to something the client sends, but IMHO
that's not the defining factor of "client/server".

Pete

 

[RedLars]

[...] My understanding of "client\server" is that only the client
sends a request to the server and gets a respond.

That's not a typical usage of "client/server".  For example, unless you're  
using passive mode, the FTP protocol allows the server to initiate  
communications to the client, but people aren't generally calling FTP a  
"peer-to-peer" protocol.

You can use that definition if you like, but do be aware that it will  
impede your communication with others.  In general, "peer-to-peer"  
actually means that either endpoint can initiate the original connection, 
while "client/server" means that there's a single endpoint that sits and  
waits for clients to connect, and the client are always the one to  
initiate the original connection.

I agree that in most "client/server" protocols, the server only ever sends  
data to the client in response to something the client sends, but IMHO  
that's not the defining factor of "client/server".

Pete

I understand. Thanks.