xheavenlyx
The points you have given on your previous post Desi, ive been thinking of something...
* A CLI app which is standalone as you said. Portable without disturbing reg.
* Create kind of an interface which can accept "add-on" and "extentions" to expand the existing functionality. This could be achieved by making .dll's / .ocx's / .CEx (our own format!!) and then updating the main CLI to run these new functions. (someone explain how this is done normally.)
Before i suggest some functions i want to know, will we be using a 24/7 server to store somethin...or will we connect to each other like a P2P? i am a layman on networking...so if desi could write a small technical tutorial on ways of communication etc, it would be reallyy helpful, (you know how to explain!)
so for now, this is from me...Let the ideas flow in!!!!!!!
Regards!
Regarding your analogy of plugins, is quite interesting. It allows more customization, and gives the power to write your own plugins as well, if you wanna go that deep. But in this case, let us refer to them as 'modules'. Cos i think the word 'plugins' has been abused too much..
From what I've learnt so far from the other CE'ans on the forums, I believe the requirements for a CE messenger will have to satisfy some of the following conditions..
1) Must facilitate intelluctual communication (ex: IRC). Not just personal (ex: yahoo, msn )
2) Must augment the website in such a way, that the users should feel at home, such that there should be minimal distinction between the messenger and the website as far as aesthetics is concerned. Trust me. Aesthetics is very important.
3) It must be able to do most of what can be done in IRC. Implementing them module wise is very viable and might prove surprisingly interesting. VOiP, though far off right now, shouldn't be omitted completely. Skype is like yahoo and msn in the VOiP segment. As far as I know, there is no IRC equivalent for VOiP. Maybe we can fill in that niche.
4) For the interface, I would still prefer it be CLI. But like you say heavenly, if a GUI could be added as a module, that would be perfect. So that way, those who want CLI use CLI. Those who want GUI, use GUI. Simple.
5) xheavenly, this is in regards to your last question, with regards to the network topology that we should think about using. Being the most important aspect of the messenger, I don't think we should use Client/Server mode. In my opinion p2p is the way to go. Im not talking about a hybrid. I mean a true p2p, that can scale itself accordingly. i'll give you the reasons...
Client/Server
---> Network solely depends on a server.
---> Server gone, network gone.
---> Needs hardware implementation( server ) along with sofware implementation.
---> Cost of server.
---> Not economically scalable. If more users join, another server becomes necessary.
---> Maintaining a centralized database is a cause for security concern.
---> If the server that hosts the database is hacked, network comes down. What's worse is that, if our login and registration details are stored in the database, then that becomes public as well.
---> I know we need not think about all this right now. But this concern will have to be addressed one day. Better now than later. Better be safe than sorry.
Now in the following i'll describe the kind of network setup that I think we must use. It is similar to p2p, but optimized for our kind of communication. Here is the abstract..
---> Let us assume there is CE'an 'A' using the CE messenger. Since he is the first to start the network, lets call him the soul.
---> He sends a broadcast signal ( multicast packet ) of his SYN flags ( TCP protocol, RFC # - 793 ) at regular intervals.
---> Just google RFC protocol # 793. You'll understand. Its too long to describe here. Sorry about it.
---> The broadcast signal consists of 'A's public ip address and a standardized port he is listening on. Lets assume for CE messenger its gonna be 7251.
---> Another CE'an called 'B' is using his messenger and it is already listening for a broadcast packet from the standardized port.
---> 'B' has already sent his broadcast packet. Now, whoever gets the other's broadcast packet first, will send a SYN-ACK flag acknowledgement to the IP address that 'A' or 'B' will receive. (Again plz see RFC 793. Its too long)
---> If 'A' receives the broadcast first, then it sends an ACK flag to 'B'. Now connection is established.
---> If 'B' receives the broadcast first, then it sends an ACK flag to 'A'. Now connection is established.
---> Since 'A' and 'B' are connected, they can chat, share files (dcc mode), VOiP, VPN... and other modules that we may implement.
---> Now that both of them are connected, they will draft a real time database of all the users that are connected to each other.
---> In this case 'A' will have a database saying it is connected to 'B' and 'B' will have a database saying it is connected to 'A'
---> Here the database doesn't have to be SQL, Oracle or anything exotic like that initially. A simple text file will do, just with the user ip and name. No need for port address. That is same for all peers.
---> Now if another CE'an 'C' wants to connect. He does the same procedure of sending a broadcast packet.
---> But this time the response will be different.
---> After 'C' sends his broadcast packet, either 'A' or 'B' will get it first.
---> If 'A' gets it first, it won't send an SYN-ACK flag to 'C'. On the contrary, it will send the database instead. Now 'C' has a choice of choosing to connect with either of the CE'ans in the database
---> 'C' can choose to connect to the nearest CE'an. This can be performed on the basis of network optimization
---> Like this more and more users can be connected to each other while simultaneously balancing the load while more and more people join.
---> The only problem here is with the soul CE'an. If the soul is in the US and the only other CE'an is in India, then they will have to wait for hours before they can connect cos they have to go through all the gateways between them before connecting.
---> That is the only problem I can think of for now.
Some of the advantages of using a p2p system would be
---> Network doesn't solely depend on a server. Because there is no server
---> No network down time. As long as there is still a single peer remaining, the network is still alive.
---> No hardware implementatino required. All the necessary hardware needed is provided by the CE'ans themselves in the form of their computers. No extra bandwidth required. Remember, as the number of people connecting increases, the bandwidth available to the network increases proportionally. In my opinion, this is the best feature of p2p. In client/server, it is impossible to achieve this.
#-Link-Snipped-#
#-Link-Snipped-#
---> Server cost is out of the question
---> Economically it is very scalable. As the number of CE'ans the price doesn't increase. Infact, i dont see a reason to believe that there would be any cost associated with it at all.
---> There is no centralized database. Each peer will only have a list of those peers it is connected to. So eaves dropping becomes a challenge.
---> As an icing on the cake, I don't think there is any other software that serves the purpose of messenger, using p2p...... 😉
What I have said above is not set in stone. It is open to peer review. All that I have said is just the tip of the ice burg. There are many details i have omitted. The reasons being that, I, myself might be unaware of them. We will run into many implementation problems once we start. My description is solely based on topology. Performance issues may arise if it might be implemented as is. It will have to go through repetitive rounds of refinement to get the best combination of performance, scalability, security and feasability. For that, we will need to fix some holes.
I guess, what Im trying to say is that we need more people to pitch in with their ideas to choose the one that will suit our purpose.
Side Note:
I tried to make it as clear as possible. Sometimes understanding from reading text alone, can be hard. That is why I have drawn 2 jpegs. Check them out. It might help your understanding. If i had an opportunity to talk, I would be able to make you all understand easily. I'll probably get that opportunity sometime later. 😀 Until then Peace.