Peer to Peer Chat

[NT.]

Hi,

I am new to developing an application like peer to peer chat. I have no clear ideas how to start developing that and till now I didn't found any tutorial that are really helpful in understanding the basic concept behind peer to peer communication, Like how the peers communicate,h ow to establish and test the connection etc. I did found some information regarding client/server chat application, but that is still not very helpful. Can anyone suggest me some good tutorial that can give me good knowledge for peer to peer chat.

Thanks!

[Diamonddrake]

Client / server is the basic concept, the only difference is, in Peer to Peer one of the Peers acts as the Server and the Other acts as a client, you simply write in the ability for each end to be able to be the server, the only real difference is the server must be waiting for connections and the client initiates the connection.

[NT.]

Does this mean that we still need to create a server? It says its just communication between clients. Also, Do we need to start server before the client can try to establish connection? I am sorry if you feel the questions are very basic but I haven't done anything in this area before.

Thanks!

[Diamonddrake]

I just started working with socket just recently I read a book on it, there is a link to a PDF here in the forum somewhere that ddanbe posted. anyhow.

the Idea is all network connections of any kind work in a client/server relationship, even if its peer to peer, the Idea behind that is, the program that initiates the connection is always the client, and the program that is listening to for the connections is always the server. In the case of your peer to peer chat system, all of your clients should be listening for connections(servers) but be able to connect to a remote endpoint(like a client) that way you cover all your bases.

but that is just a simple program model, if you wanted to do a 3 or more person chat system, it would be best if all the other clients all connected to the one client that was the original server, a relaying messages to mass users when they are all connected in a spider web could get really confusing.

[sknake]

There is a few samples of various chat systems on code project. Here is one example:
http://www.codeproject.com/KB/IP/TCPIPChat.aspx

In the case of p2p just make a single application and either user could be the server or client. Whoever initiates the conversation will be the server and the other is the client. Then you have p2p :)

[Hidden-Coder]

None of these are actually Peer-to-Peer. P2P Chat would be connectionless, therefore its is not a client/server model. True P2P Chat would be an application on a host PC that would broadcast itself on a unique port and not caring which other host PC receives and processes the information, doing the same for messages it sends - Hence, Connectionless. This would require use of the UDP Routed protocol.

Just my 2 cents.

[Hidden-Coder]

It may be worth your while using Google to find out how P2P networks work and also look into how TCP and UDP protocols work.

[sknake]

None of these are actually Peer-to-Peer. P2P Chat would be connectionless, therefore its is not a client/server model. True P2P Chat would be an application on a host PC that would broadcast itself on a unique port and not caring which other host PC receives and processes the information, doing the same for messages it sends - Hence, Connectionless. This would require use of the UDP Routed protocol.

Just my 2 cents.

I disagree with that entirely. Connectionless peer to peer is one form of p2p. You can also have a p2p architecture that uses TCP.

Peer to Peer - A peer connects to a peer. No server involved.

Chat program:
NodeA to NodeB: Lets talk, connect to me on :2505 TCP
NodeB to NodaA: sounds fun, i'm connecting

No server. Peer to peer. TCP.

[Hidden-Coder]

I understand where you're coming Scott. However to me it seems that you're still using a server in that case. What happens (in your example) when NodeA goes down or disconnects? If another Node, for example NodeC, connects and is speaking to NodeB and NodeA goes down, they would no longer be able to speak to each other.

Lets us know what you think.

Matt.

[sknake]

I think you're over thinking it. If NodeA goes down and disconnects then nodeB will sit there waiting around for NodeA to come back online. We're talking about Peer-to-peer here, it seems like you're referring to fault tolerant bittorrent transfers. It may use peer-to-peer because there isn't a centralized server per se, but that isn't the only definition of peer to peer.

[Diamonddrake]

straight from Wikipedia
"A pure P2P network does not have the notion of clients or servers but only equal peer nodes that simultaneously function as both "clients" and "servers" to the other nodes on the network. "

If you have any idea on how the internet works, you would understand that in order for computers to communicate they have to know where each other are, and in the case of TCP. the only real distinction between client and server is that the server is the first side to be contacted.

most p2p apps like kazza, frost wire, limewire, ect. have server somewhere they login to just so the other p2p clients know where to find each other. its just a big IP address and port sharing server.

now your p2p app has 2 basic threads running, (its more complicated in many but this is how the system works) the client thread starts making connections to all the available p2p apps, while its server thread is listening for connections from other p2p apps.

when someone uploads from you, its the server side of the app that sends out that information.

when you request files an download them TO your computer, its the client side of the app that receives the information.

just because the terms are client and server doesn't mean they meet the typical client/server model , they are all CLIENTS and they all SERVER each other.

[Diamonddrake]

None of these are actually Peer-to-Peer. P2P Chat would be connectionless, therefore its is not a client/server model. True P2P Chat would be an application on a host PC that would broadcast itself on a unique port and not caring which other host PC receives and processes the information, doing the same for messages it sends - Hence, Connectionless. This would require use of the UDP Routed protocol.

Just my 2 cents.

even UDP typically uses connections. and most routers, especially the ones that your ISP uses to provide your connections will not pass on packets that have no definite endpoint attached to them. So if you use that method, then you are not going to get out of your local network, might fly in a large building with all private equipment. but not over the internet.

the standard is, if its not bound to an endpoint, then its noise, and squelch it! Its basic network coding theory. I have read it in 3 networking books, including the one that ddanbe posted a link to in a different recent thread.

[Hidden-Coder]

Thanks for the theories. It looks like that the term Peer-to-Peer is far too broad of a concept to be summarized in one paragraph - despite what the "meaning" may be, depending on where you go. My approaching method to this was based on a LAN only topology.

I still disagree on some points - but thats the beauty of opinions, everybody has them.

Cheers.

[mikiurban]

sknake is correct that you can define peer-to-peer both ways, connectionless and connected.

Connectionless P2P
SNMP is a popular connectionless protocol, it is used by a lot of servers and network service boxes (routers, printers, etc) to broadcast their statuses, errors, etc for others on the network to hear. These have no idea if anyone is listening to them or not, and they keep merrily broadcasting away anyway. However, like DiamondDrake mentioned, packets without a specific destination are never going to make it to the Internet. Can you imagine the traffic if every message sent by every device had to reach every other device on the net? This is how Code Red and other worms shut down the internet. Thus, UDP would be a great solution for creating a p2p chat program that never leaves your local lan.

Traditional Client/Server
In a traditional client-server, each client connects to a central server in order to do anything. World of Warcraft is a good example of this. The only connection the client ever makes is to the server. Even if it seems like you are talking directly to someone else, your chats first go to a server, then get forwarded to your buddy. If the server goes down, everyone gets disconnected and all activity stops. Except for the people who keep clicking "logon" waiting for the server to come back. We aren't talking about c/s here, but it helps explain what makes p2p be p2p.

Common P2P
When people say peer-to-peer, they are usually talking about this. Internet P2P (torrent file sharing is a good example of this) has each peer act as both a server and a client: each peer waits for another peer to connect to it (this waiting is the server-like behavior) and each peer sending out connection requests to another is the client-like behavior. Frequently, each peer shares the list of IPs it is connected to with the other peers. They keep sharing with each other, and if one peer gets disconnected, everyone else can keep talking. While Hidden-Coder is correct that there are many definitions if p2p, 99% of the time this is what is meant.

Footnote: Modified C/S and P2P Combo
The original Napster: a client would log into the Napster server, and the server would remember what data the client hosted. Any searches for data would be sent to the server, which would return the IP addresses of other clients that had that data. Next, the client would connect to these other clients to begin p2p mode. If a peer got turned off, the other peers kept working. If the Napster server got turned off, the peers would keep talking, but no new searches could be performed. This is how Napster could be shut down (they turned off the server) and also why torrents can't.

Thank you for listening to History of P2P on the Discovery Channel.

[mikiurban]

Oh, yeah, sorry we derailed your original request about creating a peer 2 peer chat program. What you want to do is do a search for normal client/server communications and let your chat program do both.

System.Net.Sockets.Socket is a good class to start, and you will probably base your "server" aspect on the BeginAccept() function, and your client aspect on the Connect() and Send() functions.

Create a serializable class that has at least a "Command" and "Data" member, and send instances of that object back and forth between each other. Sample commands are "Connect", "Disconnect", "Chat", and "RequestForOtherPeerIpAddresses" and "HereIsAListOfOtherPeers" (you might want to shorten those last two.) The "Data" would hold things like my display name for the "Connect" request, "dude, we should hang out!" for "Chat", etc.

Good luck!