Because of the way IP is designed, everything is a client-server.
IP is a connectionless, stateless packet protocol. There is no concept of "client" "server" "connection".
BOTH parties must have be listening for IP packets. Then they send IP packets at each other. There isn't even a concept of port numbers.
TCP is designed to be client/server. Then, one party must act as a server and have a listening socket, while another tries to establish a connection with an active open. You also introduce, with TCP, the concept of port numbers, which allow multiplexing of connections to different machines, and different processes on those machines. But TCP is built on top of IP, and there is a lot of overhead that goes into establishing and maintaining those connections.
UDP is built on top of IP, and there is absolutely no concept of "client/server"*. UDP simply provides the multiplexing capabilities of port numbers and a checksum facility to improve reliability.
* You can have a connected UDP socket, that throws out packets not from a specified ip/port, but really, it's just a big hack. ---
It would not be in place of TCP, it would be on top of it. But you knew that. My point is, TCP is still necessary, and this new protocol could extend the functionality and efficiency of TCP to deal with more modern applications.
Sure, TCP is already multiplexed, but there is a lot of overhead inherent in this mulitplexing scheme as TCP cannot distinguish between 10 connections to 10 different machines or 10 connections to one machine. They are all completely seperate connections, all with seperate kernel space buffers, all doing their DNS lookups, all having seperate windows and flow control and connection states, etc, etc. There is a lot of overhead that goes into making a TCP connection; it is very noticeable to the end user.
This protocol, by allowing ONE TCP connection to describe ALL transactions between two machines, can reduce overhead on both machines, and reduce load times and processing consumption. See my reply to the post above yours.
It does serve a purpose. And it is in no way a replacement for TCP. It does not provide the connection, reliability, flow control, etc, capabilites of TCP. It is a stream format, not a packet-level format, as such, it MUST be built on top of TCP, as TCP provides a state-oriented, stream oriented connection on top of a connectionless, unreliable, stateless datagram packet protocol that is IP. ---
TCP has a lot of connection overhead, with the three-way handshake and four-way disconnect. And, with small datasets, it is a waste to send too many TCP segments.
For example, a webpage may contain 4k of text, and say, 20 2k images. Why make 21 TCP connections, when you can make one, and send the whole page in one XML stream? That is a big overhead savings, and the page will load MUCH faster. Even for something like slashdot comments, where there's about 200k of text and maybe 10 images, that's still a savings, although not as much.
Simply bandwidth wise, (assuming 0 RTT), a TCP/IP segment header is 40 bytes. A connection requires 3 packets + 4 to disconnect = 280 bytes per connection. An sequence of XML tags would probably be smaller, in addition to reducing wait time and processor load. ---
The internet tends to be cordoned off into various "sectors." Thus from the RIAA's site, you can link to RIAA-liking links, and then from those, they merely link to more RIAA-liking links, because they are RIAA-liking sites to begin with, and do not want you going to, say, napster.com or mp3.com. Most "illegal" sites are probably linked to by "illegal" or semi-"illegal" sites. Furthermore, they probably only link to "illegal" or semi-"illegal" sites. * Note that this does not include, say, going to geoshitties' main page from a geoshitties page that is used to store warez, because that is not a link that is part of the actual content of the page, and was not put there by the author.
...then most of the internet is [illegal] But of course!:) The internet is evil. ---
I'm curious if the download part of Gnute.com is still peer2peer/dchp, or if it's from downloadee to gnute.com to me. I'm sure it's not the latter, since that would kill gnute.com's bandwidth.
Gnutella can use HTTP to transfer files. So the Gnute service simply provides you with URLs formed to point to the users' static IPs. ---
IP is a connectionless, stateless packet protocol. There is no concept of "client" "server" "connection".
BOTH parties must have be listening for IP packets. Then they send IP packets at each other. There isn't even a concept of port numbers.
TCP is designed to be client/server. Then, one party must act as a server and have a listening socket, while another tries to establish a connection with an active open. You also introduce, with TCP, the concept of port numbers, which allow multiplexing of connections to different machines, and different processes on those machines. But TCP is built on top of IP, and there is a lot of overhead that goes into establishing and maintaining those connections.
UDP is built on top of IP, and there is absolutely no concept of "client/server"*. UDP simply provides the multiplexing capabilities of port numbers and a checksum facility to improve reliability.
* You can have a connected UDP socket, that throws out packets not from a specified ip/port, but really, it's just a big hack.
---
server: SYN ACK (40)
client: ACK (40) "GET / HTML/1.0"
Hmm, only 134 bytes!
---
Sure, TCP is already multiplexed, but there is a lot of overhead inherent in this mulitplexing scheme as TCP cannot distinguish between 10 connections to 10 different machines or 10 connections to one machine. They are all completely seperate connections, all with seperate kernel space buffers, all doing their DNS lookups, all having seperate windows and flow control and connection states, etc, etc. There is a lot of overhead that goes into making a TCP connection; it is very noticeable to the end user.
This protocol, by allowing ONE TCP connection to describe ALL transactions between two machines, can reduce overhead on both machines, and reduce load times and processing consumption. See my reply to the post above yours.
It does serve a purpose. And it is in no way a replacement for TCP. It does not provide the connection, reliability, flow control, etc, capabilites of TCP. It is a stream format, not a packet-level format, as such, it MUST be built on top of TCP, as TCP provides a state-oriented, stream oriented connection on top of a connectionless, unreliable, stateless datagram packet protocol that is IP.
---
For example, a webpage may contain 4k of text, and say, 20 2k images. Why make 21 TCP connections, when you can make one, and send the whole page in one XML stream? That is a big overhead savings, and the page will load MUCH faster. Even for something like slashdot comments, where there's about 200k of text and maybe 10 images, that's still a savings, although not as much.
Simply bandwidth wise, (assuming 0 RTT), a TCP/IP segment header is 40 bytes. A connection requires 3 packets + 4 to disconnect = 280 bytes per connection. An sequence of XML tags would probably be smaller, in addition to reducing wait time and processor load.
---
Neither AltaVista, nor SlashDot, are building their reputations and profitably solely on the basis of pirating copyrighted music.
---
Ah, but isn't that the purpose of SDMI?
---
Yes, but the Yellow Pages is not known by and for its listings of bootleg record stores.
---
The internet tends to be cordoned off into various "sectors." Thus from the RIAA's site, you can link to RIAA-liking links, and then from those, they merely link to more RIAA-liking links, because they are RIAA-liking sites to begin with, and do not want you going to, say, napster.com or mp3.com.
Most "illegal" sites are probably linked to by "illegal" or semi-"illegal" sites. Furthermore, they probably only link to "illegal" or semi-"illegal" sites.
* Note that this does not include, say, going to geoshitties' main page from a geoshitties page that is used to store warez, because that is not a link that is part of the actual content of the page, and was not put there by the author.
But of course!
---
Gnutella can use HTTP to transfer files. So the Gnute service simply provides you with URLs formed to point to the users' static IPs.
---
It was excel, not word.
---
No.
---