Note: while your question is leaning towards being broad, I am answering it since I think that it is a good introductory question.
TCP is a layer-4 (or transports layer) protocol. Network applications sit on top of it (and other layer-4 protocols like UDP). Applications can interface with Layer-4 protocols via a socket interface (http://linux.die.net/man/7/socket). HTTP is also an application that runs on top of TCP and would be using the socket interface. Besides HTTP, there many other famous applications that run on top of TCP, like Telnet, BGP, etc.
One of the best book to understand basics of TCP and options would be "TCP/IP Illustrated, Vol. 1: The Protocols" by Richard Stevens. It talks about how TCP works and various options. Here is a link: http://www.amazon.com/TCP-Illustrated-Vol-Addison-Wesley-Professional/dp/0201633469
Once you have read that, you probably should read the RFC itself: http://www.ietf.org/rfc/rfc793.txt
For details of implementation, you can read its second volume: "TCP/IP Illustrated: The Implementation, Vol. 2". Here is a link: http://www.amazon.com/TCP-IP-Illustrated-Implementation-Vol/dp/020163354X . While this books talks about BSD implementation -- it should still help you understand the basic mechanics of how TCP implementation works.
If you're dead-set on using blocking IO to get this done, you should investigate the setsockopt() call, specifically the SO_SNDTIMEO flag (or other flags, depending on your OS).
Be forewarned these flags are not reliable/portable and may be implemented differently on different platforms or different versions of a given platform.
The traditional/best way to do this is via the nonblocking approach which uses select(). In the event you're new to sockets, one of the very best books is TCP/IP Illustrated, Volume 1: The Protocols. It's at Amazon at: http://www.amazon.com/TCP-Illustrated-Protocols-Addison-Wesley-Professional/dp/0201633469
Check W. Richard Stevens [TCP/IP Illustrated](https://www.amazon.com/dp/0201633469). I think WIkipedia even states it, but Stevens is who I would consider the authoritative source.
I'm probably nitpicking, but *`dur.bounceme.net`* is ***not*** a FQDN. FQDN's end in dot like *`dur.bounceme.net.`*.The dot indicates the top of the DNS tree. Your hostname allows search domains to be appended, like *`dur.bounceme.net.example.com`*. Also see [Fully Qualified Domain Name](https://en.wikipedia.org/wiki/Fully_qualified_domain_name) on Wikipedia; or W. Richard Stevens' [TCP/IP Illustrated](https://www.amazon.com/dp/0201633469) for the win!
If you want to grab files using HTTP, then libcURL is probably your best bet in C. However, if you are using this as a way to learn network programming, then you are going to have to learn a bit more about HTTP before you can retrieve a file.
What you are seeing in your current program is that you need to send an explicit request for the file before you can retrieve it. I would start by reading through RFC2616. Don't try to understand it all - it is a lot to read for this example. Read the first section to get an understanding of how HTTP works, then read sections 4, 5, and 6 to understand the basic message format.
Here is an example of what an HTTP request for the stackoverflow Questions page looks like:
I believe that is a minimal request. I added the CRLFs explicitly to show that a blank line is used to terminate the request header block as described in RFC2616. If you leave out the Accept-Encoding header, then the result document will probably be transfered as a gzip-compressed stream since HTTP allows for this explicitly unless you tell the server that you do not want it.
The server response also contains HTTP headers for the meta-data describing the response. Here is an example of a response from the previous request:
HTTP/1.1 200 OK\r\n
Server: nginx\r\n
Date: Sun, 01 Aug 2010 13:54:56 GMT\r\n
Content-Type: text/html; charset=utf-8\r\n
Connection: close\r\n
Cache-Control: private\r\n
Content-Length: 49731\r\n
\r\n
\r\n
\r\n
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" ... 49,667 bytes follow
This simple example should give you an idea what you are getting into implementing if you want to grab files using HTTP. This is the best case, most simple example. This isn't something that I would undertake lightly, but it is probably the best way to learn and appreciate HTTP.
Try examples using telnet server 80 and typing in requests by hand
Download the cURL client and use the --verbose and --include command line options so that you can see what is happening
Read Fielding's dissertation until HTTP really makes sense.
Just don't plan on writing your own HTTP client for enterprise use. You do not want to do that, trust me as one who has been maintaining such a mistake for a little while now...
The short answer is no, the amount of traffic is the same. I'll caveat that with "in most cases". Multicast packets are written to the wire using a MAC address constructed from the multicast group address. Joining a multicast group is essentially telling the NIC to listen to the appropriate MAC address. This makes each listener receive the same ethernet frame. The caveat has to do with how multicast routing may or may not work. If you have a multicast aware router then multicast traffic may traverse the router onto other networks if someone has joined the group on another subnet.
[0] https://www.amazon.com/TCP-Illustrated-Vol-Addison-Wesley-Pr...
Note: while your question is leaning towards being broad, I am answering it since I think that it is a good introductory question.
TCP is a layer-4 (or transports layer) protocol. Network applications sit on top of it (and other layer-4 protocols like UDP). Applications can interface with Layer-4 protocols via a socket interface (http://linux.die.net/man/7/socket). HTTP is also an application that runs on top of TCP and would be using the socket interface. Besides HTTP, there many other famous applications that run on top of TCP, like Telnet, BGP, etc.
One of the best book to understand basics of TCP and options would be "TCP/IP Illustrated, Vol. 1: The Protocols" by Richard Stevens. It talks about how TCP works and various options. Here is a link: http://www.amazon.com/TCP-Illustrated-Vol-Addison-Wesley-Professional/dp/0201633469
Once you have read that, you probably should read the RFC itself: http://www.ietf.org/rfc/rfc793.txt
For details of implementation, you can read its second volume: "TCP/IP Illustrated: The Implementation, Vol. 2". Here is a link: http://www.amazon.com/TCP-IP-Illustrated-Implementation-Vol/dp/020163354X . While this books talks about BSD implementation -- it should still help you understand the basic mechanics of how TCP implementation works.
If you're dead-set on using blocking IO to get this done, you should investigate the setsockopt() call, specifically the SO_SNDTIMEO flag (or other flags, depending on your OS).
Be forewarned these flags are not reliable/portable and may be implemented differently on different platforms or different versions of a given platform.
The traditional/best way to do this is via the nonblocking approach which uses select(). In the event you're new to sockets, one of the very best books is TCP/IP Illustrated, Volume 1: The Protocols. It's at Amazon at: http://www.amazon.com/TCP-Illustrated-Protocols-Addison-Wesley-Professional/dp/0201633469
http://www.amazon.com/TCP-Illustrated-Vol-Addison-Wesley-Professional/dp/0201633469
If you want to grab files using HTTP, then libcURL is probably your best bet in C. However, if you are using this as a way to learn network programming, then you are going to have to learn a bit more about HTTP before you can retrieve a file.
What you are seeing in your current program is that you need to send an explicit request for the file before you can retrieve it. I would start by reading through RFC2616. Don't try to understand it all - it is a lot to read for this example. Read the first section to get an understanding of how HTTP works, then read sections 4, 5, and 6 to understand the basic message format.
Here is an example of what an HTTP request for the stackoverflow Questions page looks like:
I believe that is a minimal request. I added the CRLFs explicitly to show that a blank line is used to terminate the request header block as described in RFC2616. If you leave out the
Accept-Encodingheader, then the result document will probably be transfered as a gzip-compressed stream since HTTP allows for this explicitly unless you tell the server that you do not want it.The server response also contains HTTP headers for the meta-data describing the response. Here is an example of a response from the previous request:
This simple example should give you an idea what you are getting into implementing if you want to grab files using HTTP. This is the best case, most simple example. This isn't something that I would undertake lightly, but it is probably the best way to learn and appreciate HTTP.
If you are looking for a simple way to learn network programming, this is a decent way to start. I would recommend picking up a copy of TCP/IP Illustrated, Volume 1 and UNIX Network Programming, Volume 1. These are probably the best way to really learn how to write network-based applications. I would probably start by writing an FTP client since FTP is a much simpler protocol to start with.
If you are trying to learn the details associated with HTTP, then:
telnet server 80and typing in requests by hand--verboseand--includecommand line options so that you can see what is happeningJust don't plan on writing your own HTTP client for enterprise use. You do not want to do that, trust me as one who has been maintaining such a mistake for a little while now...
If you want an introduction to what (not why) the TCP/IP protocols are, a classic book is TCP/IP Illustrated, Volume 1: The Protocols.
The short answer is no, the amount of traffic is the same. I'll caveat that with "in most cases". Multicast packets are written to the wire using a MAC address constructed from the multicast group address. Joining a multicast group is essentially telling the NIC to listen to the appropriate MAC address. This makes each listener receive the same ethernet frame. The caveat has to do with how multicast routing may or may not work. If you have a multicast aware router then multicast traffic may traverse the router onto other networks if someone has joined the group on another subnet.
I recommend reading "TCP/IP Illustrated, Volume 1" if you plan on doing a lot of network programming. This is the best way to really understand how all of the protocols fit together.