p2p or client server socket application?

jonneymendoza

Supreme [H]ardness
Joined
Sep 11, 2004
Messages
6,420
whats the difference between the two? i know p2p is for use with programs such has instant messanger but what about client/server socket type applications? are they teh same has p2p?
 
P2P implies a distributed system with a central server connecting users. When a user connects to another user, they typically both are client and server to each other.

Think BitTorrent, you connect to the central server, where it shares other users info. A user and you are downloading from each other, you are both client and server.

HTTP / FTP are basic client - server interfaces.

Not all messengers use P2P, because if a users is on a NAT, they would only be able to send messages to users outside the NAT. Having the central server take care of eliminates the issue.
 
so p2p is has its limitations. what would b the best way in creating a IM application to be used on on a LAN and maybe later on expanded to a WAN??
 
Well, how would you want this IM or P2P app or whatever to be structured? Do you want something like AIM or ICQ with centralized servers holding information like buddies, or a kind of giant chat where everyone who connects to the can talk to everyone else?

Make a simple program that just sends messages back and forth from user input isn't that hard, but the direction you take it could be.

I've written some rudimentary IM-type clients and chat servers (hell, just had to write one today to test out whether or not my school blocks TCP streams), they're not so bad.
 
On one level client/server and P2P are the same - there's always somebody waiting for a connection and somebody initializing it. The difference is that, with P2P, everyone is connecting to everyone else on the network (thus the name Peer To Peer) rather than just connecting to a single, central server that needs to handle all the clients & communications between them.

In general, P2P is not ideal (for security reasons) for something like an IM client and, since the bandwidth required for small text messages is low, there's no major incentive to use P2P to distribute bandwidth requirements (file transfers between clients are a different story). Client/Server also makes the client simpler since it only has to worry about a single connection that it initializes rather than having to worry about an arbitrary number of connections, some of which may be incoming.

In an ideal world where server computing power, reliability & bandwidth are unlimited, server costs are insignificant and there are no legal roadblocks to having a centralized server, there would be no real need to write P2P applications. In the real world, however, these factors must be considered and P2P is one way to mitigate them.
 
There is a reason most IM applications implement some form of central server, and that's because it's just plain easier to do that way. If you were to do it P2P you'd have to worry about NAT redirection, broadcasting IP's to all nodes to be able to find someone to connect to, etc. Sometimes P2P is better, say file transfer, but even most of those implement some form of central server to allow the two "points" to find each other, because it's just easier (there are exceptions, Gnutella I believe does distributed search, as did kazaa and a few others).
 
Back
Top