It looks like you have the makings of another product.  Have you thought about this?

Russ Brown (Using C#2010/SQL Server 2008)

I did some research/test projects on this, but got derailed. However, here is what my current thinking is:



- .NET has all you need to handle the network communication. A TCPListener/TCPClient I believe. That part seems pretty darned easy.

- Threading will be key, so if you aren't up to speed on threading (asynch especially), read up on that.

- Serialization is also key to how you pass data back and forth. You'd likely just use the binary serializer, but I didn't get that far to know.

- You need to know how to make a Service. Not rocket science and was pretty straight forward. I am using a book (which was pretty marginal, but I still learned the basics). Not sure I'd recommend it, but it is working for me.

http://www.amazon.com/Programming-Windows-Services-Microsoft-Visual/dp/073562433X/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1233971392&sr=8-1



This is of course just the underlying plumbing that allows the client to talk to the server. You'll need the class(s) that would actually manage the business rules. I think what trent was talking about is creating a class, especially within the client, that makes it very easy to handle the communication. This class would wrap the code that actually uses the TCPClient, bundles up any data, sends message and processes result.



Not much, but that's all I got so far...keep us updated!

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

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

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

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



Have a great Christmas!

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 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, 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.

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