which protocols are important of the network protocol.?
-
I am reading the TCP/IP Illustrated Volumn1 the Protocol. I find that is hard to acknowledge so many protocol. So I want to know which protocol are important for the network development. Is the Volumn 2 needed to read?
You don't need to know every detail of the TCP/IP protocol stack for network development. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
You don't need to know every detail of the TCP/IP protocol stack for network development. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
It really depends on your needs. For instance, if you want to use sockets for developing a chat application then a general understanding of the
TCPprotocol would be required. :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
I am reading the TCP/IP Illustrated Volumn1 the Protocol. I find that is hard to acknowledge so many protocol. So I want to know which protocol are important for the network development. Is the Volumn 2 needed to read?
I agree with you. It's a lot of information, so how can someone decide which protocols are important? Well, depends on who you are asking. If you are a beginner most in this book isn't needed, the author is a legend in his field, but I would rather start with practical experience to make yourself familiar with one thing at a time. There are very few cases where someone would need to know all low-level and high level-protocols in use like ARP, ICMP, IGMP, DNS, TFTP, BOOTP, TCP, TELNET, FTP, HTTP, SMTP and DHCP. I would pick one that you are interested in and then dig deeper. If you are already familiar with networking, let's say using TCP/UDP/DNS, it could be interesting to dig deeper and see how things work in detail and how on a deeper OSI-level. Let's say how IP/TCP/UDP/routing/switching/ARP works, definitely worth the time in the log run! But it could also that you want to specialise in application layer protocol design, then it would be better to focus on HTTP/IMAP/SMTP/POP/XMPP, the theory and design decision behind them. Another area to specialise is encryption, which algorithms have been used trough time, how to exchange keys/certificates and how communication integrates with applications. Regarding Volume 2, not sure. The only book from W. Richard Stevens I personally own is UNIX Network Programming: Networking APIs: Sockets and XTI. Very detailed book, he really enjoyed writing about the topic and it's a classic if you are into network programming. Hope it helps! /M
-
I am reading the TCP/IP Illustrated Volumn1 the Protocol. I find that is hard to acknowledge so many protocol. So I want to know which protocol are important for the network development. Is the Volumn 2 needed to read?
For 95% of programmers there are no important protocols. You'll just use a programming library to interface with the network. With TCP/IP you'll be using sockets (although older UNIX variants use another API known as TLI - I've not seen it in the wild in years though). So for the programmer the API is the most important thing. Sometimes it's helpful to know the details of the protocols you're using (i.e. when something goes wrong and you're forced to use a packet sniffer or the like) but it's not a daily occurrence. The most useful protocols to know about are probably TCP and DNS as they're the things you're closest to when you're programming. Cheers, Ash Edited as I messed up the author, confusing him with Doug Comer whose books cover the same ground