Server to Server Communication - Sockets, mailslots, etc - Which is best?

Hey guys,

I'm starting to make a new application. Basically the app will be installed on all the servers in my LAN. From there i want all servers to communicate with each other, however i'm having a hard time trying to think of a good way to do so. I want something that's extremely reliable, and easy to implement without too much overhead.

before i go further, this communication is going to be fairly minimal. Basically each server will kind of 'ping' all the other servers running the app. A simple 'are you alive' kind of message needs to be sent out and a response sent back confirming (pong).

It will also be sending some short strings of information as well (like an email address, and few other little things), so i can't simply just icmp ping the servers, or whatever.

So far the only ways i can think to do this are Sockets and mailslots. Sockets, i'd really like to stay away from, as they can be nasty to debug and use in the way i would need to use them. Mailslots seem also to be dead, and could be very difficult to find documentation on. If i did use sockets, I think UDP sockets would be ideal for this situation.

I welcome any suggestions, thanks!

How about Web Services? Then Server A can call a function on server B passsing the strings you need.

well, that's what i thought originally too.. a couple problems with that though...

1) All services would have to be running IIS... This might not always be the case....

2) If IIS goes down, i won't be able to communicate anymore... This is not ideal since IIS can go down at anytime, but the rest of the services may be up and running... And then when the other instances of the app on other services can't get through they'll think the server has bsod'd

i'm thinking that sockets might be the best way about it... trouble is i don't want to use tcp sockets since they are more for maintaining connections... I don't want to keep connections going between all the servers... This is why i'm considering udp sockets, however there doesn't seem to be much documentation on udp sockets...

I'd like to suggest remoting, which is the basic method that web services uses anyway (sort of). Although I don't think you like remoting. It seems I always suggest remoting for your questions. I think Remoting or sockets would be the best way.

well, i guess i don't like remoting simply because i haven't really been able to use it yet (properly)... i haven't found any documentation that is easy enough to understand...

i don't like sockets because i HAVE used them ;) ... they're sort of a pain to work with...

So i suppose i will research a lot more tonight about remoting... i've been avoiding it all this time, but i guess i can't do so forever. :D.. and i was afraid the topic might come up...

Will there be one central server or is it strictly peer to peer level? Once you get a handle on remoting I think I'll find it very useful.

nope, i will for sure not use any type of centralized server... that's why it's kind of a tricky situation.. basically each instance of the app is it's own server. Each machine should be able to talk to all the other machines running the app...

basically i'm going for a web/node/blanket coverage of the network, so that if one pc goes down, all the other ones are still in contact with each other, and they will notice that it goes down...

is this gonna be tricky to do remoting with?

Well I think it will be a little tricky with either remoting or sockets. UDP might be good but you are right there isn't much documentation on it and it doesn't ensure that the data gets to where its going. If things get slow today I'll try to drum up a small sample to help you out.

what about multicasting? i'm not sure what exactly this is, but it sounds like it may help me...


basically here's the structure:

the app has a server and client part to it... the client part is simple, doesn't need to be multithreaded or anything, i only want to send out one message at a time...

the server part needs to be multithreaded as it could be receiving messages from multiple clients at a time...

what i'm thinking of doing now, is making a tcplistener open all the time.. it accepts sockets and listens to each socket on it's own thread... since connections won't be maintained, this should be a quick process. each thread basically accepts a message and then that connection to the client is closed...

the client of course is simple, i connect to the desired host, send a message, and disconnect, then i'm ready to send another message...

any thoughts?

Will each machine run the client and server part to create the peer to peer effect? I think Multicasting and UDP go hand in hand, not sure though.

yep, each machine runs the client and the server part.. to give that peer to peer effect... so in essence, the application is a client and a server... for some reason i have a feeling that UDP is used for this type of situation... the only problem of course is that UDP messages are not guaranteed to be delivered, however i might be able to work around that.. lets say i send a message to one client and that message doesn't come back, then i keep trying to send to that client for a designated amount of times (lets say 10 times), and if after 10 times i still get no response then i know somethings wrong, because at least 1 out of 10 of those udp packets should be received...

apparently multicasting is taking a list of ip addresses and sending out the same message to them... broadcasting is sending out the same message to all ip addresses available (like a range, or like all addresses on the same lan)...

i guess now my decision is basically which way is going to work the best for me... btw Edneeis, i REALLY appreciate your contributions to this problem... i always enjoy your opinions and help...

i just put together sender and receiver tcp classes, testing them in the same app, basically sending myself messages so the same app sent and received them...

it worked very smoothly to do so.. i obviously didn't get to test the multithreading out on the receiver class too harshly, but it was recycling resources very well and there was no glitches...

Is there any need for this to run as a service? Also what kinds of messages will it be sending? Or what is the general idea of the app, just curious?

The program is basically a server monitoring tool...

There are about 6 servers on the LAN that i want to keep monitoring in case any windows services go down, or in case the machine totally crashes and bsod's or something...

this app will be installed (the exact same app) on every server in the LAN that i want monitored... Then, all of the servers with the app running will basically talk to one another, creating a web of communication/monitoring... the idea here is to run without a centralized server, for redundancy... if one server goes down, all other servers can still talk to each other...

the app itself monitors windows services on the local machine... if IIS or Print spooler, or ASP.NET State Server (those are just examples) goes down, the machine is still capable of running... so the machine itself sends out an email or some kind of SOS type message to a cell phone/pager/whatever alertting them what service has gone down, etc...

Now of course if the whole machine totally crashes, the server isn't going to be capable of sending out its own help message... this is why i'm networking all the other servers in the lan together with this program. Each server will send a sort of "ping" message to all the other servers running this software in the lan.... If one server goes down, it obviously won't respond to the ping messages... So, the first server to recognize that another server is down sends an SOS message out for that server that went down... this help message won't be as detailed obviously, but will basically be an urgent "help, this server has crashed hard" message to cellphone/pager/whatever...

so, the idea really is just to make a decentralized monitoring service... i realize that relying on tcp is the bottleneck here though, but i figure if a server's tcp or network connection is down, then it's as good as the whole server being down... so, i think this should suffice...

anyways, it all started out by some services crashing... and we figured it would be nice to have something to tell us when iis goes down or something instead of finding out a few hours later after sites have lost hits and business....

Right on, sounds like a very good idea. The only trouble I see and its fairly minor is: if a server crashes wont you get 6 SOS emails? How will all the other servers now a message has been sent and to not send anymore, since they will all be checking each other?

yep, i have thought about this already, and so far i don't have a perfect solution, but i'm getting there... my idea is, that all servers will eventually see the downed server, so i'm going to make it sort of like as soon as a server spots a downed server, they'll send out a message to all the other servers saying that it is going to take care of sending out the message...

now this presents a couple problems:

1) - what if 2 servers see it at the same time and both send out the sos and then send messages out saying they'll take care of this.... the server "pinging" will probably be once a minute or so, so this should hopefully offset itself enough that it will not be a big problem... though there may be times when more than one SOS message is sent out...


2) - what happens when a server is down and the SOS messages go out? i need to make something so that they don't keep pinging the server and sending out SOS messages... this wouldn't be a good thing... what i may try to do is once the servers see the downed server, and one server claims responsibility for sending out the sos message, they will all put the downed server in a marked list of downed servers and will stop checking the server until someone who gets the server back up that was down resets the program... then when the downed server is reset, the downed server sends out a message telling everyone it has joined again...

that is basically how i will make the mechanism for joining the 'network'... once a server starts the app, the app tries to connect to all the machines in the workgroup, to see if they are running the program, and makes alist of those machines to monitor...

so, aside from problem number 1, i think i have sorted things out fairly well. if you can think of a good way to solve the first problem, i'm all ears.. :)

(I realize this is an old message, but I wanted to reply anyway)

Set up a server heirarchy. Have each check the server above and below itself. Should one fail, check the next one higher or next one lower until two see each other. When two see each other, the higher in the chain will be the one to send the message out.