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.

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

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.

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?

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

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!

Hi Greg,

Sorry for the delayed reply.  Thanks for the info, you are right about .NET having all the tools needed to handle the communications, but sometimes 3rd party libraries will offer easier and faster approach to the solution.

Also thanks for the book recommendation, I will get it, since I have a lot to learn about Windows Services, I have done some work with Services with my VFP applications in the past, but for what I have read with VB.NET is much more easier since there is a special project to create a Service application.

I will keep up posted on my findings.  The more I think about this, the bigger this whole Windows Server/Console Application will be in order to manage a commercial application license and connections.

Why will you go with the polling approach instead of keeping the TCP socket alive all the time for the client?

Also would the Console Server project be based on SF with Security?, so in other words would this program be using the SF security to allow only authenticated users to modify the Service? if so, this will mean that 2 projects (Server and Client) will be sharing the security database, right?

Agree with your statement, but in my case I see the Server Service as a Licensing Manager in which the clients must or should be connected all the time in order to communicate with the database. Here are more details of my thinking:

1. Server Console is a regular SF project which will use the Connection Manager to get the database connection info to be passed over the Client.
2. Server Console will be protected by my security software to be properly licensed to the end user.  This has nothing to do with SF except that this program will be wrapped with this protection for me to control the licenses.
3. Only clients under the same local network (Intranet) will be able to communicate with the Server to get the database connection string and other stuff in order to operate properly.  Of course the client is a regular SF application with modifications to connect to a Server first instead of the database.
4. So my plan was to have the client connection alive during the client session, so if the connection with the Server is broken, then the connection with the database will also be broken providing a minute or two to the end user to save any pending changes back to the database.

Yes this is the case, my security/protection library will enforce the License on the Server instead of dealing with all possible Client workstations, so at this point the customer can have a Local Network with x number of workstations and I will need to worry about the Server Service and Server Console application to be properly protected and licensed. 

In regards to using the SF security, what I meant was that since the Server Console is also a SF application with access to the database, I can implement the SF security so only users with specific role can connect to the Server Console after it has been setup by the administrator or initial default user when installed.

Greg, in regards to your original question I found this sample at the nSoftware site: http://www.nsoftware.com/kb/tutorials/jabber.aspx I have not test it yet, but it looks pretty easy to implement.

This topic is getting better and better!

Greg,

Just want to thank you on the recommendation of this book "Programming Windows Services with MS VB 2008" so far it has been pretty good to me in getting started with all the understanding about Windows Services.  Oh, btw, I got it new from Hightech Computer at amazon.com for $13.99 includind shipping charges.

I am doing the following, in the Service application I have a BO which will hold the list of all connected workstations and this BO will be updated OnConnect and OnDisconnect to add/remove the records, now in the Server Console application I have a list view in which I want to show the data in the Service BO, I am still not clear how to accomplish this, but here are some ideas:

1. The Server Console will also connect to the Service application with a different parameter to let it know that it is the Server Console and the service will pass a serialized BO to the Server Console to show the connected clients in the listview. Still I don't know how to do the serialization process but guess it should not be hard.
2. The Server Console can create an XML file with the connected clients and the Server Console can read this file, etc.  This approach could be more difficult to handle since I will need to have this XML file in an specific folder and also would need a timer to keep reading from each and it would be a lot of IO traffic.
3. From the Service application I could create an Instance of the Server Console application, but that would be also a bit complicated.

So, from all 3 above I would go with option 1, but before I continue further could you or somebody else comment on this or any other recommendation to handle this?

Thanks!

You will want to have a "service port" that is exposed on your service application to which the server console will connect to administrate and retrieve all information.  You can still use sockets on this, but for arguments sake, let assume that we will use port 20010 as the administration port on the service application.  When the server console fires up, it will communicated with the service on that point to obtain information...but it should not "crash" if the service is down.  In fact, if run on the same machine as the service, it should be able to start, stop, and restart he service from within the server console:

This just makes it easier for the end-user as well...especially in service call type of scenarios.  But through this port, you can do whatever you need...send serialized BOs back and forth, etc.  In all actuallity, I would probably not send a serialized BO back and forth in this case, but rather create a query type of situation where I send a request and a response, not unlike web services.  This way you can create a NetRequest class and a NetResponse class (or whatever you want to call them) that wrap this logic for you and know how to send and receive the NetStream data on both sides...so if you WANTED to send over a serialized BO you could.  For populating a list with the connected users or something that would probably be fine.  But these are just some ideas of how we designed our server service and console that might help.

Thanks for the info.  Now back to serialization, I am trying to use the SerializeToByteArray but it is not working for me, I have the feeling my code is not correct, here is  my approach:

' Serialize the BO into a ByteArray
Dim pszOutByte As System.Byte()
pszOutByte = Me.bizConnectedClients1.SerializeToByteArray

' DeSerialize the BO from a ByteArray
Dim loBO As New bizConnectedClients
BusinessLayer.DeserializeBusinessObject(e.TextB)
Me.BizConnectedClients1.CopyDataFrom(loBO, BusinessCloneDataType.ClearAndFillFromDefaultView)
loBO.Dispose()

In above code e.TextB contain the serialized BO byte stream. When testing this I get the following error when trying to Deserialize the BO:

SerializationException
  The input stream is not a valid binary format. The starting contents (in bytes) are: 34-31-36-32-32-34-36-33-0D-0A-54-65-73-74-20-4F-6E ...
Source     : System.Windows.Forms
Stack Trace: 
   at System.Windows.Forms.Control.EndInvoke(IAsyncResult asyncResult)
   at nsoftware.IPWorks.Ipport.nsoftware.core.IIpportEvents.FireDataIn(Byte[] text, Boolean EOL)

What is it that I am missing here?

And you will need to type is as well.  So it would look more like this:

Just a note to say thanks again.  So far I was able to create my version of a Server Console and a Server Service using the IP*Works library from www.nsoftware.com and the book for Windows Services suggested by Greg in this thread.

This has been a great experience working outside of just the database process, using secured XML files managed by the SF Business Object to store the Server Settings information and using a ListView with all the goodies of the SF BO to show connected clients without saving any data to a database, this whole process shows once again the power in the SF framework.

On a side note, I was having a lot of trouble with the IP*Works and sending the BO as a byte array, despite Trent's support replies I could not make it work to a satisfactory level, so I decided to simply use a predefined string which I then parsed and it worked just great.

Thanks guys!

We do allow it if the server cannot be automatically located.  We use a UDP boradcast from the client if it cannot connect t the server.  The server is listening on that UDP port and sends out a UDP broadcast of its location to which the client will retrieve the servers location and login.  You can find a lot of samples on the internet about this.  I did a quick serach and found some CodeProject samples.  Here is a chart sample that uses a UDP broadcast.

http://www.codeproject.com/KB/IP/socketsincs.aspx?fid=2956&df=90&mpp=25&noise=3&sort=Position&view=Quick&select=1070795