P2P Chat Program...

[Pc_Madness]

Hey guys, just looking for some opinions on how I would go about developing a P2P chat program (in C++ or VB...which ever is easiest :p).

I'm not sure for example if theres any secure way of being able to identify the differences between two clients on the network to allow someone to have a "contact list", the only way I can think is by using Public/Private Keys... but someone could easily listen for the key being sent and then send that key instead, or how much P2P programs spam the network with their broadcast messages... or if its going to take a few billion lines worth of code to implement it all?

Just looking to throw some ideas around atm. :) The program is meant for use at university, so its not supposed to be some MSN replacement thing. :p

Thanks in advance. :)

[k1ll3rdr4g0n]

VB would probably be easiest IMO. You could setup a username/pass for the person to log into the P2P app.

Prehaps it could work like this?
Client -> Server -> Client

Where the client would make a search and send it to the server, and the server would search all connected client's shared folders. And if there are results found then the server would send the found files (just the filename) to the client. And if a Client does want to download something, you have 2 options A. Have the data go through the server, or B. Have the data go Client to Client and no middle man.

A. Client A <- Server <- Client B
B. Client A <- Client B

Edit:
Wait..is this a P2P Chat program where youll just be chatting, or will you be transfering files to?

[Pc_Madness]

Well, chatting and sending files will be the aim, but its 1 to 1 file transfers rather than something like BitTorrent or whatever where you upload and download pieces of the file from multiple people.

The problem with a client -> server, is that I'll be running it at uni, and I would most likely be the server, and I won't be at a computer all the time, so the system isn't going to work, and I don't have any computers where I could just leave a server program running. :\

[k1ll3rdr4g0n]

Hmm..Well the problem mostly is going to have to deal with the chaning IP's (Im assuming the IP's there are dynamic).

Say you put "TheBeastMaster" with the IP of 12.12.12.12 on the client. Ok, the 2 clients can talk until "TheBeastMaster" disconnects from the internet, or the other client disconnects. Thats what the server handles, it makes sure it goes to the right person.

I don't know how you would be able to do something like that. Prehaps every Client is a Server? And work it like the Kazaa network? (A computer can be a node and maybe every node can corespond about whos on the network?)

-shrugs- I think I saw that some people were making one, or has made one, on the forums. I definatly would read over how Kazaa works, though. Because Kazaa doesn't have a central server. :wave:

[Pc_Madness]

Yeah, my only concern though is how much traffic its going to cause when a user comes online, as its going to have to broadcast it across the network when they go online... and I guess the other problem is that on MSN for example, your email address is secret, so you don't have to worry about any old random person finding it... but if your broadcasting that your at such and such a computer, anyone could add you to their list.

[Vis3R]

for the IP issue ... maybe install no-ip (www.no-ip.org) .. get a host to your dinamic IP and problem solved ... if u're affraid your data will be sniffed encrypt it and decrypt it on the other client ...

[Pc_Madness]

IP Addresses aren't a problem, as it can't be server based, as there are no places to setup, thus it has to be P2P (true P2P, not a hybrid..).

Well, encryption isn't the problem so much... its just the fact that I'll be broadcasting messages about Bob coming online to everyone (there goes the ability to block someone without them knowing), and that anyone could potentially use the details send in the broadcast to add Bob to there contact list... so assuming that we have a system where the other person has to approve whether or not if someone can talk to them, it could get very annoying very quickly if someone uses a custom client that picks up everyone that comes online and adds them to there list.

I guess a dodgy work around is that there are no messages asking permission, merely a kind of central listing of all the people curently online and people would choose from that.

I have a few concerns over how the hell your supposed to prevent someone from simply sniffing the packets being sent as someone comes online/adds you to their list allowing them to pretend to be you as well. I would assume that you would use a hash of say a username and password, and then perhaps store the hash on the persons contact list, so when someone comes online claiming to be such and such, you can check it against the hash stored on your contactlist, otherwise dump it as a fake. But that wouldn't stop them from tricking other people who don't already know your hash into thinking they were that person.

I don't think the system can really work without an authentication server, which I won't be able to have.

[Vis3R]

ok ... well i think there is a problem with IP cause there's no server ... how will you know the IP of your friend? ... asking him every time you want to connect to him what his ip is isn't very usefull ... if you set a host to your IP .. like .... myclient1.no-ip.org ... he can always connect to it whatever your IP is ...

ok your problem about verifying of fake or real friend ... code your username/password with MD5 or something ... then send it with your request you'll send to your friend to add you .... after your friend add you once ... ( u tell him to add you ) ... his client save the md5 somewhere ... and after he accept you his client send you his login coded with md5 ... now when you 2 connect to chat ... the client sends the md5 login to each other and if they match the connection is enstablished ...

about the data encryption ...
let's say i sniff your data like "ߣߤ¨ßŁłŁł|€|!" (the data yoru client encrypted) .... even if i have a custom made client i won't be abble to know what that means to your client ... i won't be abble to add another one .... cause i won't be able to encode it (if u do a good encryption) ...

:wave:

[Pc_Madness]

ok ... well i think there is a problem with IP cause there's no server ... how will you know the IP of your friend? ... asking him every time you want to connect to him what his ip is isn't very usefull ... if you set a host to your IP .. like .... myclient1.no-ip.org ... he can always connect to it whatever your IP is ...

about the data encryption ...
let's say i sniff your data like "ߣߤ¨ßŁłŁł|€|!" (the data yoru client encrypted) .... even if i have a custom made client i won't be abble to know what that means to your client ... i won't be abble to add another one .... cause i won't be able to encode it (if u do a good encryption) ...

:wave:
You let people know your IP address by broadcasting it across the network, and if your friend recieves your broadcast message, retrieves the ip address and establishes a connection with you... generally from what I've learnt you can get mini-servers. For example you broadcast it a short distance, someone on the network picks up your message and forwards it onto people that they know and perhaps they broadcast it onto there network, and anyone on that network may try to reconnect back to you, but broadcasting only travels so far to prevent flooding. Have a read, http://en.wikipedia.org/wiki/P2P if your not familiar with it. I believe the Gnutella uses the mini-server style above, not sure about KaZaA.

All transmission has to be initially unencrypted so that you can establish the connection....atleast I think so... unless you encrypt the message with your hash saying that you've connected, then only those who know your hash would be able to tell who it is..perhaps.. the broadcast message would have to contain say a command identifying it as someone coming online, and then the second argument would be a hashed string that you would have to be able to decrypt, which would have the ipaddress of the sending computer (not sure if when I broadcast if the packets will contain my ip address?)