Re: Simple Client Server design

Tech-Archive recommends: Speed Up your PC by fixing your registry

One problem of multicast sockets is that they work well only on a local network. Routers
have to be configured to forward multicast packets, and most intermediate routers are
specifically configured to NOT forward multicast packets.

And, of course, multicast is UDP, which means you really won't know if the packet is
received or not.

If you are working on a local network, you could consider mailslots as a way of having the
server make itself known to the clients; they wouldn't have to poll for its presence but
just wait on a mailslot (a client becomes a mailslot "server", the server is the mailslot
"client", just to add confusion, so watch out for this inversion). Then you could use
named pipes or sockets as you see fit.

Note that sockets cannot be secured like named pipes; instead, you have to impose
encryption levels on top of the socket protocols (e.g., SSL) to secure the content.
joe

On Thu, 30 Nov 2006 09:54:47 -0600, "AliR \(VC++ MVP\)" <AliR@xxxxxxxxxxxxx> wrote:

I would use sockets for sure. One thing that comes to mind here is that if
all the clients will receive the same information, and that number of
clients could be large (30 or more), I would use a multicast socket. Using
a multicast socket you will only have to send the message out once from the
server, and all the clients that subscribe to that multicast address will
receive the message.

Keep in mind that multicast socket uses UDP, which is unreliable (My program
runs on a LAN, so it has been very reliable). So what I would suggest is
this. Have a mulitcast socket setup and back it up using a TCP sockets from
each client. What I mean by this is that when the client is connecting,
connect using two socket, the multicast, and a TCP. Then when you send your
message out to everyone using the multicast socket, (if you are in a LAN
environment then chances are 99% will receive the message) and any client
does not respond back with an acknowledgment then send them the same message
on the TCP socket.

I have been using this model for years, in a software that is not forgiving
of any delay. Every client has to be synchronized, and it has been working
flawlessly.

AliR.


"Michael Sandler" <msandler@xxxxxxxxxxxxxxxxxxx> wrote in message
news:1164870344.804565.105030@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I have an application receiving data every minute or so which needs to
broadcast that data to any other subscribing application on the
network. My dilemma is how best to implement this.

There could be times when there are no clients and times when there is
no server. I am not sure whether to use a Named Pipe or an Asynchronous
Socket or some other option. Currently the client is polling for a
NamedPipe to appear and send it data (on a seperate thread), which
obviously slows down everything on that machine if the server isn't
there. I can't work out how to implement non-polling waiting.

A nudge in the right direction would be most appreciated.

Michael


Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Socket switch delay
    ... both at the client and at the server (and why ... would you set the send buffer size to zero on a non-overlapped ... One glaring error is your client does ... So when you use a single socket, ...
    (microsoft.public.win32.programmer.networks)
  • Re: Locking on async calls
    ... you must synchronize the entire SendMessage routine as an atomic ... operation to prevent mixed messages from being transmitted to the server. ... You are correct that read and write on the socket do not interfere with each ... If you want to handle multiple client connections from one server object ...
    (microsoft.public.dotnet.general)
  • Re: Design issue with WinSock/GetQueuedCompletionStatus
    ... delegate that to a shutdown routine called after all worker threads ... The application I've created is a server accepting connections on a few ... different TCP/IP ports and then lets the client run different commands. ... a TCP/IP socket can be closed for 2 different reasons: ...
    (microsoft.public.win32.programmer.networks)
  • Re: socket communication: socket doesnt connect
    ... Microsoft MVP, MCSD ... As far as your server code goes, ... accept the listening socket. ... Client client = new Client; ...
    (microsoft.public.vc.language)
  • Re: TCP server stop receiving new connections
    ... reset the event mask of your listening socket each time you ... I have a strange problem in my class library used by all our client ... server applications. ... incomming connections, but keeps current connections. ...
    (microsoft.public.win32.programmer.networks)