- Forum
- General C++ Programming
- Design problem
Design problem
I'm trying to figure out how an instant messaging program that I'm writing will work. I don't want the program to simply connect to one computer and then allow conversation between those two computers; rather, the program should be able to connect to an arbitrary number of users per conversation and hold an arbitrary number of conversations at once. The problem I'm having is with connecting the clients together. Obviously I need some kind of server software, but I can't figure out how that will work.
One idea I had was that upon sign-in the client sent the user's IP address, username and password to a server. The server would then try to verify the password, store the IP address, username and a number (to allow sign-in from mutliple computers) to the client and send the number back. To connect to another online user, the client would request the IP address of that user from the server and then try to connect to it. When the client exited it would tell the server and send it's number and the server would remove the IP address, username and number from the database. I'm not sure how sound this idea is, though.
I also thought about doing essentially the same thing, but having the client only ever talk to the server. Each client sends data to the server and the server sends it on to the other clients. But this has it's own problems (e.g. "how does the server know who to send the data to?").
Can anyone suggest a better way?
One idea I had was that upon sign-in the client sent the user's IP address, username and password to a server. The server would then try to verify the password, store the IP address, username and a number (to allow sign-in from mutliple computers) to the client and send the number back. To connect to another online user, the client would request the IP address of that user from the server and then try to connect to it. When the client exited it would tell the server and send it's number and the server would remove the IP address, username and number from the database. I'm not sure how sound this idea is, though.
I also thought about doing essentially the same thing, but having the client only ever talk to the server. Each client sends data to the server and the server sends it on to the other clients. But this has it's own problems (e.g. "how does the server know who to send the data to?").
Can anyone suggest a better way?
Last edited on
| I also thought about doing essentially the same thing, but having the client only ever talk to the server. Each client sends data to the server and the server sends it on to the other clients. But this has it's own problems (e.g. "how does the server know who to send the data to?"). |
That particular problem could be solved but I won't explain how as I don't think this design is a good idea. Imagine this instant messenger on a large-scale, think how much data could be being sent to the server at any time.
How about upon sign-in the client sends the user's IP address and username to the server. When the user wants to connect to another computer it sends the username of the computer it wants to talk to, to the server and requests it's IP address. Once the client receives the ip address it can then attempt to connect.
| mcleano wrote: |
|---|
| How about upon sign-in the client sends the user's IP address and username to the server. When the user wants to connect to another computer it sends the username of the computer it wants to talk to, to the server and requests it's IP address. Once the client receives the ip address it can then attempt to connect. |
That was my first idea:
| I wrote: |
|---|
| One idea I had was that upon sign-in the client sent the user's IP address, username and password to a server. The server would then try to verify the password, store the IP address, username and a number (to allow sign-in from mutliple computers) to the client and send the number back. To connect to another online user, the client would request the IP address of that user from the server and then try to connect to it. When the client exited it would tell the server and send it's number and the server would remove the IP address, username and number from the database. I'm not sure how sound this idea is, though. |
I'm going with this one. With the addition of the number it allows for multiple sign-ins. The only problem now is getting a server.
Sorry I kept reading over your post so many times i kept looking at the different points you were making. I've also come to that problem before. The only solution I could come up with (some of which are temporaray I guess) are:
1) Use your own computer, which would obviously only be temporary but it would allow you to verify the code works. It does however mean that you will keep on having to change the source to match your IP.
2) Pay for a static IP address?
3) Use a free webhosting service and write a script to handle the connection details. Unfortunately I don't know enough to go into the "ins and outs" of this suggestion.
1) Use your own computer, which would obviously only be temporary but it would allow you to verify the code works. It does however mean that you will keep on having to change the source to match your IP.
2) Pay for a static IP address?
3) Use a free webhosting service and write a script to handle the connection details. Unfortunately I don't know enough to go into the "ins and outs" of this suggestion.
| chrisname wrote: |
|---|
| I think I'm just going to use free webhosting. I guess I can use PHP or something. |
That's exactly what a friend of mine did for his trojan. The clients-victims connect to his page whenever they're online, and he can send them instructions from there :P
| That's exactly what a friend of mine did for his trojan. The clients-victims connect to his page whenever they're online, and he can send them instructions from there :P |
Haha that's exactly the idea I had but as I said, I wouldn't have been able to do the script on the web host so I decided to go for a more different method. Mine also wasn't a malicious trojan but a remote desktop wallpaper changer :p (curtious of Helios' suggestion). One cool little tweak I implemented though was that both the client and the server was the same application. I never did finish writing it though...
| Obviously I need some kind of server software |
http://lacewing.aquadasoft.com/
It's a C++ library with a server and a client class ;)
It's not the software, it's the hardware to run it on. I won't be able to use native code on a free webhost's server so I'll have to use a web interface.
Topic archived. No new replies allowed.