Is TCP/IP protocol set of all the devices like Windows,Mobiles,Linux,Unix,MAC OS same?identical?
I mean is the TCP/IP protocol's source code in each OS same?no changes at all?
please answer each questions to exact point.thanks !
Jump to Post— JorgeM 958Keep in mind that there are 7 layers in the OSI Networking model. Basic network connectivity is quite different from connecting at the application level.
For example if you had a MAc and a PC on the same subnet, you can easily ping each other. However if you tried to …
Jump to Post— JorgeM 958That is false. I have worked on networks where there is a variety of operating systems on the same local area network, including Macs.
Jump to Post— rubberman 1,355The TCP/IP protocol suite was formulated by the US Department of Defense's Defense Communications Agency and originally implemented by DARPA (Defense Advanced Research Projects Agency) in conjunction with the company Bolt Beranek Newman, Inc. in Cambridge Massachusetts. The specs are in the form of RFCs (Requests for Comments) in a …
Jump to Post— rubberman 1,355Some aspects of building a TCP/IP stack from scratch are very subtle. I have a "fond" memory of sitting in a small lab/office in an engine manufacturing plant in Indianapolis to debug and fix our OOB (Out-of-Band) message handling which wasn't working properly. Three solid 12 hour days of debugging, …
Smells like homework. Instead of giving you a direct answer I will give you some information.
TCP is a protocol. It is defined [mostly] by an RFC. If you want to communicate with other TCP implementations you must adhere to at least the bare minimum of supported functionality. However, there are additional functionalities provided by each implementation that may be unique to that implementation and what is available per connection is negotiated at connection startup (the handshake).
You could write your own version (or algorithmic change to an existing version) and still have it work with legacy TCP implementations. In fact, on Linux, the vesion of TCP used can be controlled by the user by setting variables in the system (I believe Microsoft supports this to some extent as well).
well your nose is kind of bad.becasue this is not homework. Still prefer a direct answer. anybody?
L7Sqr's answer is correct. As long as you follow the standard, you'll be able to communicate with other hosts TCP hosts. The same goes for any other protocol.
someone told me that we can't connect a MAC and a Windows device together . is there any kind of network incompatibility ? anyyy kind?
Keep in mind that there are 7 layers in the OSI Networking model. Basic network connectivity is quite different from connecting at the application level.
For example if you had a MAc and a PC on the same subnet, you can easily ping each other. However if you tried to share files between then, other networking protocols and services are required.
Still prefer a direct answer. anybody?
No. No. No. No. Yes.
However if you tried to share files between then, other networking protocols and services are required.
you mean, we can't play a LAN game or share a fodler (at application layer level) between a MAC and a Windows PC?
Sure you can. You just need to have the applications that will communicate using the same/compatible application layer protocols.
Think about how users on a Mac computer can access a website hosted on a Windows server. The protocol in common is HTTP. The Safari browser includes support for HTML.
Sharing files between Macs and Windows can be done, but depending on the OS on both computers, the approach may be slightly different. the result is that you want both computers using SMB to share files.
you mean even though the soruce code may different and may wirtten in different languages, algo is the same?
did that guy lie when he told me that MAC and WIndows are different when it comes to netowrking and can't be in the same LAN ???false?
That is false. I have worked on networks where there is a variety of operating systems on the same local area network, including Macs.
awesome .thanks
The TCP/IP protocol suite was formulated by the US Department of Defense's Defense Communications Agency and originally implemented by DARPA (Defense Advanced Research Projects Agency) in conjunction with the company Bolt Beranek Newman, Inc. in Cambridge Massachusetts. The specs are in the form of RFCs (Requests for Comments) in a set of very big books called the DDN Protocol Handbook. The most popular implementation is the Berkeley Sockets Library, written by the Berkeley Software Distribution (BSD) team at the Universiy of California, Berkeley. This is the source used by most Unix and Linux distributions. FWIW, I did a complete TCP/IP implementation for a real-time operating system, working solely from the DOD White Books, as the DDN Protocol Handbooks are called, back around 1990. The handbooks came out in the 1980's - my copy is from 1985, and it takes up a good foot of shelf space. Our implementation was able to communicate over ethernet to any system that had a TCP/IP protocol stack over ethernet, ranging from mainframe computers to mini-computers to PC's.
Some aspects of building a TCP/IP stack from scratch are very subtle. I have a "fond" memory of sitting in a small lab/office in an engine manufacturing plant in Indianapolis to debug and fix our OOB (Out-of-Band) message handling which wasn't working properly. Three solid 12 hour days of debugging, coding, testing... :-)
One thing that is absolutely necessary to understand the protocols and to code them is a complete understanding of finite-state machines (FSMs). It is impossible to implement them without using FSMs extensively. In such cases, either you have to write your own FSM handling code (which I did), or you resort to a lot of lex/yacc rules. My method was more efficient because I could tune the FSMs by editing a text file of rules and restart the applications/servers instead of regenerating C code with lex/yacc, recompiling, relinking, etc. The time I saved doing that was significant - we figure it cut a year off the development time. In 6 months we had a functioning system, and there were only two of us working on it. Most of our time was spent validating the state-machines by careful analysis of the RFCs in the White Books.
wow.cool
hey how long did it take to builit TCP/IP proto set from the scratch to those guys from ARPANET in history? inventing and doing
hey how long did it take to builit TCP/IP proto set from the scratch to those guys from ARPANET in history? inventing and doing
Quite a bit longer I think. After all, Cerf et al at BBN were inventing something that had never been done like that before! My hat is definitely off to those folks! The fact that we could implement such complex stuff from just the specs says a lot to the deep thinking that went into TCP/IP, and why it is still prevelant today, running the Internet/WWW from end-to-end! OSI came along, trying to structure network stacks even more clearly, but the fact is that OSI is more a footnote today, other than conceptually, and TCP/IP still rules the roost! So, today you need to know about OSI for school exams, but you need to KNOW TCP/IP to program networks in real life.
And FWIW? Today, Vint Cerf is VP of Engineering at Google... :-)
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.