AT&T Backbone Sees 20% P2P Drop > This is alarming

reply to Reck Havoc

Re: This is alarming

TCP has already worked out rules of etiquette about who says what under what conditions, when to ask for information to repeated, and how to say hello and goodbye. TCP is fine for most uses, but sometimes it lack features you want or in the case of streaming video, it has features that you don't need.

UDP is a much looser language, where the UDP "syllables" can be used to create exactly the languages that you want. You can have the connectedness stateful nature of TCP without the retransmission request for a 10% bad packet, for example.

At some level, all hosts on the internet are peers but some peers have a central function -- e.g. they serve web pages, or answer file-transfer requests, or respond to other queries. These hosts are servers (masters) and the hosts that connect to them are clients (supplicants). That architecture is client-server. In a client-server arrangement, clients only connect through servers who arrange all of the processing and other communication. You have to follow the chain of command.

In a peer-to-peer architecture, there is no hierarchy. End-hosts communicate with other end-hosts directly and no central device is required. If there are communal processing tasks to be performed, this work is generally distributed among the peers somehow. There is no hierarchy.

I know how TCP and UDP work, I just don't know what to consider a "server" (I like precise definitions).
My logic is TCP requires one node (the server) to listen for a connection and another node (the client) to initiate the connection. But perhaps that's a faulty definition, as which node was the listening one is irrelevant in, say, bittorrent.
The purest example of a p2p paradigm I can think of is a multicast chat program, where one node doesn't know and doesn't care how many other nodes are on the network.