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.

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