[c][cpp] Guide to Network Programming

[c][cpp] Guide to Network Programming

What is a socket?

• a way to speak to other programs using standard Unix file descriptors.
• “If it's a file descriptor, why in the name of Neptune can't I just use the normal read() and write() calls to communicate through the socket?” The short answer is, “You can!” The longer answer is, “You can, but send() and recv() offer much greater control over your data transmission.”

Two Types of Internet Sockets

• One is “Stream Sockets”; the other is “Datagram Sockets”.

1. Stream sockets are reliable two-way connected communication streams. If you output two items into the socket in the order “1, 2”, they will arrive in the order “1, 2” at the opposite end. They will also be error-free. Stream sockets use a protocol called “Transmission Control Protocol”, otherwise known as “TCP” (see RFC 7936 for extremely detailed info on TCP.) TCP makes sure your data arrives sequentially and error-free.
2. Datagram sockets? Why are they called connectionless? What is the deal, here, anyway? Why are they unreliable? Well, here are some facts: if you send a datagram, it may arrive. It may arrive out of order. If it arrives, the data within the packet will be error-free. They use the “User Datagram Protocol”, “UDP” (see RFC 7688.) don't have to maintain an open connection as you do with stream sockets. You just build a packet, slap an IP header on it with destination information, and send it out. No connection needed. Example : tftp and similar programs have their own protocol on top of UDP. The tftp protocol says that for each packet that gets sent, the recipient has to send back a packet that says, “I got it!” (an “ACK” packet.) If the sender of the original packet gets no reply in, say, five seconds, he'll re-transmit the packet until he finally gets an ACK. This acknowledgment procedure is very important when implementing reliable SOCK_DGRAM applications. Why would you use an unreliable underlying protocol? Two reasons: speed and speed.

Data Encapsulation

• Basically, it says this: a packet is born, the packet is wrapped ("encapsulated") in a header (and rarely afooter) by the first protocol (say, the TFTP protocol), then the whole thing (TFTP header included) is encapsulated again by the next protocol (say, UDP), then again by the next (IP), then again by the final protocol on the hardware (physical) layer (say, Ethernet).
• When another computer receives the packet, the hardware strips the Ethernet header, the kernel strips the IP and UDP headers, the TFTP program strips the TFTP header, and it finally has the data.

Byte Order

• The thing is, everyone in the Internet world has generally agreed that if you want to represent the two-byte hex number, say b34f, you'll store it in two sequential bytes b3 followed by 4f. Makes sense, and, as Wilford Brimley would tell you, it's the Right Thing To Do. This number, stored with the big end first, is called Big-Endian. The more-sane Big-Endian is also called Network Byte Order because that's the order us network types like.While the Host Byte Order isn't right, and you always run the value through  function to set it to Network Byte Order.
• Conversion Functions : 

  htons()	host to network short
  htonl()	host to network long
  ntohs()	network to host short
  ntohl()	network to host long

Ref :

http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html
http://techpubs.sgi.com/library/dynaweb_docs/0530/SGI_Developer/books/IRIX_NetPG/sgi_html/ch04.html
http://mi.nou.edu.tw/yen/Ch8-ok.pdf
http://content.edu.tw/primary/info_edu/cy_sa/report/more/8611a8.htm