I was just playing ball with my GF and son. We were playing "think fast" and "hot potato". :)
Which makes me think of a chat program. What is it essentially doing?
Well there is a "server" that accepts connections from multiple "clients" and acts as a liaison between the clients.
Lets pose a question. Does the server have to actively liaison the clients, or does it have to appear to do so?
Well, what if the clients "fooled" each other into thinking that it was the server (securely of course) and a way made for the clients to "after authentication was established" communicate with the other clients themselves?
Seeing that it is a chat program, the main thing to fight is hacking/viruses from other peoples computers. It isnt a high tech government spy network. lol
In what way does a client interact with a server? well the server or client sends a communication to the other and some action takes place according to the stimuli.
Well if a client was to send a message to another client, it stands to reason that it would do the same thing.
Most host providers do not allow services to run, but they cant say squat about clients talking to each other.
In the client/server chat program that im going to work on sooner or later for my webiste, the server will simply be a slave to do something when called upon to do something. No reason at all this cant be a single php file with some specific stuff in there to authenticate users and establish the link between a number of clients, therefore forgoing the need to stay running.
The clients would be configured in such a way to send encrypted packets to all clients except itself. And then all the clients would then send back a response to the client that sent the message.
The entire program would not even use server resources except upon new connections and and possibly another php file for saving the conversation to a specialized topic in the forum. Potentially meetings, minutes, just a record of the conversation for legal purposes. whichever.
The means that these clients would operate, would be dependent upon the device its being operated on. A wap2 version would just simply be user refreshed regular, and probably a good few of upper end fones.
How this would work is upon refresh, is that the refreshing client would send a braodcast message to the other clients and a snapshot of the conversation would then be sent back. Now even the specifics of this would require some creativity. Each client has a tag, computer, fone, wap2, etc. well first, the chatroom cant operate without at least one computer, and each client has a list of the "computers" where each computer would share the load of acting as the server.
The point is, to get away from having to use the server as the server, cause most providers wont let you do it.
So the one or more computers in the chat list can then send an updated set of messages based on the span of time that has passed since the requesting "fone" had received its last update. one of these days this wont be a problem, but it is now, so we work around it.
Typically the person with the computer to start the chatroom, would be the main client/server, with the other "computers" to step up if the main one becomes unreachable.
The client/server would simply be the liaison between the other clients and the server/server. sort of. It would kind of be a leaderless pack, like an ant hill. There is no "active" leader, but the whole hill works together to accomplish something.
the clients would be written in a number of different languages according to what is best for the platform it is running on. A computer can run any language, so you can do anything you want. But on fones of different types, it would range from plain html, to jquery.
And basically, the same way wedge and smf detect browsers, the server/server would assign the appropriate interface. (or it could potentially be a downloadable app) And then the server/server would assign all the clients to recognize the client/server as the server to talk to when wanting to do something with a list of potential backup server ready to pick up seamlessly. Even including the ability to choose to neglect, and pass the server responsibilities to a different computer client, or kill the connection if there isnt one.
This is a basic structure of how it would work, actual implementation would of course require some trial and error to make this type of complex server client relationship work the way one would want it to. Its just a matter of looking at issues from a perspective that has no limits. Its a matter of utilizing the tools of programming languages to their fullest extent.
More to come in the future when i dive into how the server and clients would actually work.
