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!

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

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

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.

Edhy Rijo

Hi Trent,

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?

Edhy Rijo

I don't know the definitive answer to why not keep the connection open, but I can take a guess based on my research thus far. I think the first reason would be that you need to consider that the connection might not be available all the time. The internet is not the most reliable, so it is almost a guaranty that you'll need to deal with the connection being broken. And you'd have to deal with this on both sides. I think there is a reason TCP/IP was designed to be a stateless connection.



As to the security question, again I can just offer my thoughts, but I wasn't planning on using security with the server. Using SF security seems like it might be hard. How would you structure the server such that the SecurityBasics.CurrentUser would be switched and available to multiple users? It's shared so there is only going to be one instance. I'm not sure it is thread safe. I was thinking of another method, which would be to have some sort of token identifying the client as legitimate that would identify it to the server (which might simply be the client license token...which your server will validate). Also, don't make any requests of the server that might need a logged in user until the user is logged in. Then you could just pass the user ID to the server, if the user ID needs to be tracked. I.e. do user validation on client side were you have easy access to permissions.



I'm probably missing something here, but those are my thoughts.



Thanks for the updates Edhy!

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!

Edhy Rijo

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.

Edhy Rijo

Sweet!



It's not a great book. Lots of omission and typos. But it did help me a lot understanding how to do a service!



Glad your project is moving right along! I'm jealous. I've been pulled in yet another direction for the time being

Trent, I have a question about the Service and Server Console applications.

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!

Edhy Rijo

Yeah, based on your options there 1 would be best.  How you set this up will be very important in regards to scalability and growth within your application because it won't be long before you need to add some new functionality.

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.