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