I'd like to have a server app that provides a messaging service between the clients. There a few different sort of things I'd like to do:



- When certain fields are updated on a certain BO, it changes the application state. Rather than code to errors (because another user attempts something that was legal when it retrieved the state, but the state has now changed), I'd like to be able to just notify the clients so they can get the new state and adjust to it.



- For administration purposes, it would be good to know who is on, in real time. The way chat clients can show a list of friends online is what got me thinking about doing something chat like (though I don't intend to allow users to chat, just the client apps).



- For both administration and security purposes, I'd like to be able to kick off users, send out notifications etc. in real time. This would be used when the app is being upgraded, to make sure no one is on (and give them a 10 min warning). For security, in case we have a particularly naughty user, I could kick them off immediately.



I'm just a total newbie at doing anything like this. I've done a bit of research on using network streams, but don't know where to start. I'm also wondering how I'd do this if I were to use IIS and an ASPX page. I'm not sure that would work because I'd need to have a client talk to the server, which would broadcast to other clients.



Any help/starting tips would greatly appreciated!



Thanks!

Hi Greg,

Even though I have not experience doing this kind of application, it is all based on network Sockets where you will have a Server and multiple Clients to communicate via a TCP port to do all kind of things and have a lot of fun

This is one of the things I have on my list to do for my applications too, but don't know when I will ever start working on that

I goggled ".net socket server" and got several links, here is one very simple.

http://www.eggheadcafe.com/articles/20020323.asp

Also there are some communications libraries like IP Works from www.nsoftware.com which easy this kind of thing, I have not used this library, but I have used other libraries from nSoftware and they are pretty easy and straight forward to work with.  Here you can see a bunch of demos http://www.nsoftware.com/ipworks/demos.aspx available to test their libraries, I would pay attention to these ones:

• TCP Echo Client/Server
• UDP Echo Client

I am sure there should also be a Client/Server TCP/Win Socket demo application somewhere using plain .NET.

Edhy Rijo

Here is another one http://www.chilkatsoft.com/p/p_514.asp from the guys at Chilkat Software which also you can test with the demo in the link.

Edhy Rijo

Well, this is basically what we have done within our medical software.  We have a server that gets deployed with our medical software which does a number of things:

• Manages concurrent user connections
• Manages all connection strings for the clients.  This is done via UDP broadcasting so when the client starts up, it looks for the server using a unique GUID (just a unique key in case there is more than one server on the network).  Once found, the server hands the connection string information back to the client.  This prevents the client from ever having to manage or enter a connection string...this has been a very nice benefit.
• Manages the licensing.  When the client starts up, it gets all of the licensing information from the server (i.e. certain products purchased, etc.)
• Database management (i.e. backup and restoring of databases)
• Automated tasks such as checking for past due labs or running reports defined by the user on a scheduled task or time.
• Allows certain users to be kicked off by right-clicking the user and then saying "log-off."  The client then recognizes the log-off and the logically shuts down.

The screen that is shown above is the server console (not the server) that interacts with the server service.  The server should be running at all times since a lot of logic is wired into that.  The serer console is the mechanism to which the server service can be accessed for interaction.

So this begs the question, how do you do this and what approach should you take.  We took the approach of creating a listener on the server service (TCP socket).  The client communicates to the server on a poll and does not have a listener on the client side to reduce overhead on the client side.  The client's poll on a theaded timer periodically (about every 7-10 seconds) to the server.  

Based on the logic of HTTP response and request objects, we created a proprietary (to our medical software) response and request object that makes it easier in code to work with which then streams the request/response through the socket to the server/client.  This way you work with a request and response type of interface while the base class does all of the TCP work for you....this makes it much easier to work with in code and make changes or add new requests, etc.

So a request can be made from the client at any time and receive an immediate response from the server.  If you want the server to send the client a command (such as log-off) without the client initiating the request, then the server will queue the command and when the client checks in on the next poll (again, around 7-10 seconds) it will receive the queued command and shut down.  So it is basically like writing a web service (but it isn't) for a Windows service.

We have had great luck with this approach and the nice things is that is is far moire scalable that using direct TCP sockets.

Thanks for the links Edhy. The http://www.eggheadcafe.com/articles/20020323.asp link was helpful to understand some of what Trent suggested!



Trent, that was very helpful. This gets me stated in getting this done. One thing I'm unclear on is what the actual data is that is passed back and forth. All the examples I've seen (so far) are just encoding strings. Any recommendations on how to pass the actual data (which I'm assuming would all be handled by the request/response objects you suggested).



Again thanks. This is yet another example of why SF rocks!

Well, the data being passed back and forth would depend on how you create your request and response objects.  You could create a string with pipe delimmiters and then parse it on either side.  Or, you could use a BinaryWriter and BinaryRead to write the data to a byte array (kindof creating your own serialization) and then put it back to gether on the other side.  In either case, you could use a network stream to read and write to and from.

Probably the best way to go would be to use a BinaryFormater (serialization) to serialize the data and then pass it back and forth as a stream (BinaryRead, BinaryWriter).  If you do this, it would be the cleanest and easiest to expand as you move forward and add more and more logic to this server and client.

Thanks Trent. I think that gives me enough info to get started!



Have a great Christmas!

You are welcome Greg, and please keep us informed with your progress in this project.

Trent, is the Server Service using a database to hold the status information or you are using an xml file?  Also I assume you can use SF to create the Server Console application, right?

Edhy Rijo

Neither.  An internal collection with custom items.  If the service shuts down, the clients will bail out.  You don't want to store this type of information in any type of database.  If you do, then you will always fight sync and update problems.  What if the server dies, etc.  So this should all be real-time.

Yup...we did

Hi Greg,

I am about to start a new SF project to handle the Server service features.  Did yo review any of the TCP libraries here that deals with communication between clients and server?

If you have any opnion you can share I will really appreciate since I have to have this done in a week or so.

Thanks!

Edhy Rijo