Slashdot Mirror
Expert Network Time Protocol
Ben Rothke writes "If you review the thousands of Internet RFCs, you'd be hard pressed to find a protocol that lends itself to philosophical overtones, save for one -- the Network Time Protocol (NTP). The nature of time is abstract, difficult to measure and highly subjective. Yet time is a critical element in everyone's life, and in the effective operations of corporate networks." Read on for the rest of Rothke's review.
Expert Network Time Protocol: An Experience in Time with NTP
author
Peter Rybaczyk
pages
176
publisher
Apress
rating
9
reviewer
Ben Rothke
ISBN
1590594843
summary
Expert Network Time Protocol is a fascinating look into NTP, and the stories behind the science
NTP is built on top of the TCP/IP protocol suite and is used to ensure accurate time-keeping with a trusted time reference. These references can be radio signals, GPS satellites, atomic clocks, Internet-based time servers and more. NTP is powerful enough to synchronize network clocks with millisecond accuracy.
In Expert Network Time Protocol: An Experience in Time with NTP, Peter Rybaczyk merges the philosophical aspects of time with the nuts of bolts of the NTP protocol. The book is composed of two parts, the first concerned with the meta-philosophy of time, and the second detailing the inner workings of NTP. The attempt in part one to merge technology and science with philosophy is a daunting task, and most often does not succeed. The notable exception to this is Douglas Hofstadter's Gödel, Escher, Bach: An Eternal Golden Braid.
Rybaczyk creates Sam, a fictional character who walks through the history of time. It is unclear who this Sam is -- whether he is supernatural being, or someone who got root on a time server. The author writes that the transcendental nature of time and the nuts and bolts of NTP are inseparable, but I personally found it difficult to determine what message part one was meant to convey. Fortunately, part one takes up but the first 34 pages.
Where the book shines, and where most readers will find value, is in part two, which details how to effectively design, configure, deploy and operate NTP. Where part one is conceptual, part two is extremely practical. Chapter 3 opens up with a comprehensive overview of the what, how and why effective time-keeping via NTP is needed.
The book details from a business perspective why synchronized and accurate time is a universal need. From transactional integrity, airline departures, sporting events, job shift changes, to FedEx pickups and more, nearly every activity requires time synchronization to work at peak levels. Effective network administration also requires time synchronization for network login procedures, directory synchronization, backups, and routing stability to work accurately.
From an information security perspective, password and digital ID synchronization, log file accuracy and auditing, and access control security are just a few of the areas where correct time can mean the difference between success and failure.
Where time synchronization is crucial, though, is in the realm of digital forensics. An otherwise painstaking digital forensic process might be worthless if time-related evidence from network devices is not correctly synchronized. If network devices are not correctly synchronized, you can basically forget about using them in any type of legal case.
Attorney Ronald Coleman, partner and computer law litigator at the New Jersey-based Coleman Law firm explains that in a computer law case involving serious discrepancies in network log times, the prosecution would conceivably drop the case. Similarly, a civil case to recover damages from an attacker is seriously undercut by these seemingly innocuous timing mistakes. "The network managers' lack of diligence at ensuring that the time was synchronized on their systems," explains Coleman, "opens them up to serious questions in front of a jury as to whether the logs and the system data are reliable at all -- especially with a gap of more than a couple of minutes, which might be explained away by which clocks were being relied on." In fact, an error of this magnitude would make the entire network administration suspect. That could be a disaster, Coleman says, where the network tracing record plus the human beings who sloppily set the automation in motion are going to be the chief sources of evidence against the alleged computer criminal. "A snafu such as seriously unsynchronized logs is just the sort of opening that could raise the level of doubt needed to undermine the other side's case."
Chapter 3 concludes with an interesting look at the cutting edge of time protocols, specifically the Interplanetary Internet. The Interplanetary Internet project is an attempt to synchronize computer time within the realm of deep space. NASA will in due time establish a deep space infrastructure whose purpose is to support the communication needs of multiple missions. Such an infrastructure would require time synchronization, but within a radically different framework from what exists today. The Interplanetary Internet and its underlying time synchronization are intended to solve that.
Chapter 4 brings the reader back to earth and provides vital information about how to design an effective NTP architecture. The key to designing the most appropriate NTP architecture for a given infrastructure is to first understand the different modes that NTP devices can operate in. The chapter details the five different NTP modes, the mode categories, and gives configuration information about each mode.
The chapter also provides information about NTP security. While NTP versions 3 and 4 provide added security (including symmetric private key cryptography and support of the Autokey protocol), it is ultimately up to the organization to determine what level of NTP security they need. Those organizations that don't require accurate time won't need much NTP security. But for those organizations who business requires synchronized and accurate time, such issues will drive the implementation of how they deploy NTP and its security functionality.
Chapter 5 details how organizational motivations (again, from a business perspective) will affect how you design your NTP architecture, and then describes several use scenarios. The book notes that designing an effective NTP deployment is a process that embodies four key steps: choosing a time source, deciding upon the NTP topology, determining the NTP features to configure, and then monitoring and managing the NTP operations. The chapter then goes on to describe various ways these steps can be carried out. The chapter provides a comprehensive overview on how to deploy NTP, be it on a dedicated time server, via already deployed products such as Cisco or Juniper routers, or on Unix/Linux/Windows file servers.
It is important to note that NTP is just the protocol. The actual implementation of NTP requires separate software client and server applications. The book focuses on the protocol and does not get into any specific vendors, other than a few screen shots from the configuration menu of a Symmetricom time server.
The author notes that on the surface, NTP is simple and almost inconspicuous, and overshadowed by better-known protocols such as HTTP, FTP and DNS. But once you start digging into NTP, you are dealing with one of the most pervasive elements of existence, namely time. Within NTP's scope, one could be dealing with atomic clocks, GPS satellites, clock selection, encryption algorithms and much more. So while at its heart, NTP may be a simple protocol, there is a complex infrastructure beneath it.
NTP is one of the most fundamental, yet overlooked services in the TCP/IP suite, and time synchronization is one of the most overlooked areas in networking. Hopefully, a book such as this can spark a renaissance. For far too long, time synchronization has not been afforded due diligence, and the effects have at times been disastrous. A view of the archives of the Risk Forum digest attests to this fact.
After a somewhat murky start in part one, Expert Network Time Protocol: An Experience in Time with NTP provides the reader with a superb synopsis of nearly everything he needs to know about NTP and effective time synchronization on his network, from an experienced implementer in the field. It is a fascinating look at one of the most humble, yet fundamental protocols on the Internet. For those who care about the correct time on their network, this book is required reading.
Ben Rothke, CISSP is a New-York based security consultant with ThruPoint, Inc. and the author of Computer Security: 20 Things Every Employee Should Know. He can be reached at ben@rothke.com You can purchase Expert Network Time Protocol: An Experience in Time with NTP from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
NTP is built on top of the TCP/IP protocol suite and is used to ensure accurate time-keeping with a trusted time reference. These references can be radio signals, GPS satellites, atomic clocks, Internet-based time servers and more. NTP is powerful enough to synchronize network clocks with millisecond accuracy.
In Expert Network Time Protocol: An Experience in Time with NTP, Peter Rybaczyk merges the philosophical aspects of time with the nuts of bolts of the NTP protocol. The book is composed of two parts, the first concerned with the meta-philosophy of time, and the second detailing the inner workings of NTP. The attempt in part one to merge technology and science with philosophy is a daunting task, and most often does not succeed. The notable exception to this is Douglas Hofstadter's Gödel, Escher, Bach: An Eternal Golden Braid.
Rybaczyk creates Sam, a fictional character who walks through the history of time. It is unclear who this Sam is -- whether he is supernatural being, or someone who got root on a time server. The author writes that the transcendental nature of time and the nuts and bolts of NTP are inseparable, but I personally found it difficult to determine what message part one was meant to convey. Fortunately, part one takes up but the first 34 pages.
Where the book shines, and where most readers will find value, is in part two, which details how to effectively design, configure, deploy and operate NTP. Where part one is conceptual, part two is extremely practical. Chapter 3 opens up with a comprehensive overview of the what, how and why effective time-keeping via NTP is needed.
The book details from a business perspective why synchronized and accurate time is a universal need. From transactional integrity, airline departures, sporting events, job shift changes, to FedEx pickups and more, nearly every activity requires time synchronization to work at peak levels. Effective network administration also requires time synchronization for network login procedures, directory synchronization, backups, and routing stability to work accurately.
From an information security perspective, password and digital ID synchronization, log file accuracy and auditing, and access control security are just a few of the areas where correct time can mean the difference between success and failure.
Where time synchronization is crucial, though, is in the realm of digital forensics. An otherwise painstaking digital forensic process might be worthless if time-related evidence from network devices is not correctly synchronized. If network devices are not correctly synchronized, you can basically forget about using them in any type of legal case.
Attorney Ronald Coleman, partner and computer law litigator at the New Jersey-based Coleman Law firm explains that in a computer law case involving serious discrepancies in network log times, the prosecution would conceivably drop the case. Similarly, a civil case to recover damages from an attacker is seriously undercut by these seemingly innocuous timing mistakes. "The network managers' lack of diligence at ensuring that the time was synchronized on their systems," explains Coleman, "opens them up to serious questions in front of a jury as to whether the logs and the system data are reliable at all -- especially with a gap of more than a couple of minutes, which might be explained away by which clocks were being relied on." In fact, an error of this magnitude would make the entire network administration suspect. That could be a disaster, Coleman says, where the network tracing record plus the human beings who sloppily set the automation in motion are going to be the chief sources of evidence against the alleged computer criminal. "A snafu such as seriously unsynchronized logs is just the sort of opening that could raise the level of doubt needed to undermine the other side's case."
Chapter 3 concludes with an interesting look at the cutting edge of time protocols, specifically the Interplanetary Internet. The Interplanetary Internet project is an attempt to synchronize computer time within the realm of deep space. NASA will in due time establish a deep space infrastructure whose purpose is to support the communication needs of multiple missions. Such an infrastructure would require time synchronization, but within a radically different framework from what exists today. The Interplanetary Internet and its underlying time synchronization are intended to solve that.
Chapter 4 brings the reader back to earth and provides vital information about how to design an effective NTP architecture. The key to designing the most appropriate NTP architecture for a given infrastructure is to first understand the different modes that NTP devices can operate in. The chapter details the five different NTP modes, the mode categories, and gives configuration information about each mode.
The chapter also provides information about NTP security. While NTP versions 3 and 4 provide added security (including symmetric private key cryptography and support of the Autokey protocol), it is ultimately up to the organization to determine what level of NTP security they need. Those organizations that don't require accurate time won't need much NTP security. But for those organizations who business requires synchronized and accurate time, such issues will drive the implementation of how they deploy NTP and its security functionality.
Chapter 5 details how organizational motivations (again, from a business perspective) will affect how you design your NTP architecture, and then describes several use scenarios. The book notes that designing an effective NTP deployment is a process that embodies four key steps: choosing a time source, deciding upon the NTP topology, determining the NTP features to configure, and then monitoring and managing the NTP operations. The chapter then goes on to describe various ways these steps can be carried out. The chapter provides a comprehensive overview on how to deploy NTP, be it on a dedicated time server, via already deployed products such as Cisco or Juniper routers, or on Unix/Linux/Windows file servers.
It is important to note that NTP is just the protocol. The actual implementation of NTP requires separate software client and server applications. The book focuses on the protocol and does not get into any specific vendors, other than a few screen shots from the configuration menu of a Symmetricom time server.
The author notes that on the surface, NTP is simple and almost inconspicuous, and overshadowed by better-known protocols such as HTTP, FTP and DNS. But once you start digging into NTP, you are dealing with one of the most pervasive elements of existence, namely time. Within NTP's scope, one could be dealing with atomic clocks, GPS satellites, clock selection, encryption algorithms and much more. So while at its heart, NTP may be a simple protocol, there is a complex infrastructure beneath it.
NTP is one of the most fundamental, yet overlooked services in the TCP/IP suite, and time synchronization is one of the most overlooked areas in networking. Hopefully, a book such as this can spark a renaissance. For far too long, time synchronization has not been afforded due diligence, and the effects have at times been disastrous. A view of the archives of the Risk Forum digest attests to this fact.
After a somewhat murky start in part one, Expert Network Time Protocol: An Experience in Time with NTP provides the reader with a superb synopsis of nearly everything he needs to know about NTP and effective time synchronization on his network, from an experienced implementer in the field. It is a fascinating look at one of the most humble, yet fundamental protocols on the Internet. For those who care about the correct time on their network, this book is required reading.
Ben Rothke, CISSP is a New-York based security consultant with ThruPoint, Inc. and the author of Computer Security: 20 Things Every Employee Should Know. He can be reached at ben@rothke.com You can purchase Expert Network Time Protocol: An Experience in Time with NTP from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
But I just synched my clock and it turns out I'm ten minutes behind.
It was far too long and I have far too little time to read it.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
NTP is built on top of the TCP/IP protocol suite and is used to ensure accurate time-keeping with a trusted time reference.
Ummm, doesn't NTP run over UDP?
Does this really matter? I mean NTP works, which is great, so do I really need to understand the "meta-philosophy" behind NTP? All I know is that I have the two Domain Controllers sync to 6 outside machines (reliable servers), and all the machines internally sync off thoes two.
All the computers in the network are within a second of eachother - and thats good nuff for me.
snowulf.com
It works fine in BSD, but you dont need a whole book, just tick the NTP box during the install process. (Linux is probably the same).
Sent from my ASR33 using ASCII
... without any of that mumbo-jumbo from RFCs can be found here [warning: PostScript file]. It's well written, and the safeguards and filtering techniques are very interesting.
- shadowmatter
Be sure to purchase these books on other such stimulating topics:
Ping, For Dummies!
Gopher: The Next Generation
All you ever wanted to know about the "yes" command
DJB's clockspeed package:
http://cr.yp.to/clockspeed.html
Includes an SNTP client, TAI client, TAI server, and clock correction program. It's very simple and it keeps my entire cluster to within a very small amount of drift of the atomic clock, with the sync interval doubling at every sync.
I use SNTP to get Stratum-1 time from NIST, then TAI to serve Stratum-2 time to my cluster.
I would just like to say that seeing articles like this one... well, it doesn't help speed up the recovery process. It's like leading an alcoholic to the door of a bar.
My humor is probably your flamebait
Lunchtime, doubly so. ;P
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
I tried to explain this to my boss when I showed up for work at 10:30 today. But he's such a moron, he didn't understand it. Instead of being impressed by my knowledge and intelligence, he fired me. Dammit!
slashdotters would find it interesting.
The most annoying thing about dealing with NTP for me was that nowhere in the documentation or on the 'net was there a clear, simple, one-command way to sync a machine's time to a given time server.
Tsunami -- You can't bring a good wave down!
You need a book for this?
/setsntp:ntp.yourisp.net /resync (windows 2k3)
C:\>net time
C:\>w32tm
C:\>w32tm -once (win 2k)
Really, all most of us need to know about NTP can be found on Ntp.org.. Particularly useful is their NTP Pool project, which uses DNS aliasing to allow you to sync from random servers, and avoid placing a burden on any one server.
Rybaczyk creates Sam, a fictional character who walks through the history of time. It is unclear who this Sam is -- whether he is supernatural being, or someone who got root on a time server.
We do know, however, that he has a holographic partner named Al who talks to a computer named Ziggy a lot, and that he hopes that his next leap will be the leap home.
---If you can't trust a nerd, who can you trust?
At your command prompt type $ cal 9 1752
explain.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
Chapter 3 (a look at the cutting edge of time protocols, specifically the Interplanetary Internet) should be pretty short.
In a relativistic universe, the concept of absolute simultaneity is gone. Given two events separated in space (like two nearby supernovae, or two alarm clocks going off), depending on their speeds and distances, two observers may disagree on which one occurred first, even after they make various relativistic corrections for their own speed.
If two observers can't agree on simultaneity of two events, they will not be able to agree on the correct time.
Of course, this won't matter practically within the solar system, but between solar systems, it could start to make a difference.
HCG 50a = 2MASX J11170638+5455016
11h17m06.4s +54d55m02s
Precisely how long has it been since this guy last got laid.... DON'T ANSWER IT'S AN INFINITE LOOP!
"Time, time, what is time? The Swiss manufacture it, Italians squander it, French hoard it, the Americans say it is money and the Hindus say it does not exist.
I think time is a crook".
From "Beat The Devil", 1953:
http://www.imdb.com/title/tt0046414/
The revolution will NOT be televised.
I contend that time is truly an illusion based on our perception of the laws of physics. Consider this: According to our perception of time, events, changes in state, motion, etc., all of these things "take time" to occur. While sometimes we can't precisely know when an event will occur (the uncertainty principle in quantum mechanics, for example) we can say positively that we never perceive all events in the universe occurring simultaneously. Thus we "perceive" the passage of time. However, we also always measure the rate of time passage as a constant (it always passes at the same rate, except during tax time). For example, even if we were traveling close to the speed of light, our measurement would be that time would pass at exactly the same rate for us. Others who were not moving close to the speed of light would also measure time passing at the same rate as they always had. In other words, if we both had atomically precise clocks with each of us, both of us would report that each second took exactly 9,192,631,770 oscillations of a Cesium-133 atom.
:). As space contracts (we speed up) or expands (we slow down), from the outsider's point of view of course, the room we have for events shrinks or grows in step with the change in our space. From our point of view, our space remains constant and so our room for events remains constant. In this regard, time could alternatively be considered a physical property of space itself instead of the matter found in space. But it doesn't seem likely that time is it's own dimension. Not that we really understand what a dimension is...
So what? That could mean that time is simply a physical property of matter and energy (whatever they are). Just as matter has inertia and takes up space, it also has a property that says all of the events that matter can participate in cannot happen simultaneously. There is only "room" for so many events in a given amount of space. (I'm trying to avoid using the word "time"
I think it's time for a beer...
The NSA: The only part of the US government that actually listens.
...there's a human for every task. For every tedious nerdy task that needs doing you'll find some human who will not only work on it, but will enthuse over the subject matter and do their job well. Whether it's maggot farming or telling the time this is a wonderful thing. But there's no need to tell everyone else about your job.
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
Maybe this is why I'm not a protocol engineer.
I am trolling
Only measurements of change events compared against arbitrarily chosen units (rotation/revolution of *our* planet around the Sun and fractions thereof).
Few people need sub milisecond accuracy of full NTP, and if they do there's a few nice servers available for that, for clients a simple client is all you need, and it's not that complex, you send a UDP datagram asking for the time, you get one back with the time in it, if your feeling fancy you can even improve SNTP by calculating network delay and factoring that into the time calculation.
Oh, and on the subject of hitting Stratum-1 servers... I'm not too worried about it. An NTP client may be configured to hit them every hour, or some such nonsense, but as I stated in my post, every time I hit NIST I double the amount of time I wait before I hit them again.
... ... ... it will be 28 and a half days before my cluster touches NIST again. After that, it will be 56 days... etc. If you notice from the log output, the previous interval was 14 days, and in those 14 days we only drifted 3 hundredths of a second.
We had to move our cluster onto a new UPS about a month ago, so I just have a 33 day uptime on my local Stratum-2, but as you can see:
----------------------
Sleeping 1228800 seconds
before: 2005-08-14 23:36:57.248578000000000000
after: 2005-08-14 23:36:57.218957999778524040
before: 2005-08-14 23:36:57.268270000000000000
after: 2005-08-14 23:36:57.268270000333328132
----------------------
Sleeping 2457600 seconds
I doubt any Stratum-1 guys want to punch me for syncing at the intervals I do...
This sounds to me like the first thing a hacker should do is to screw up your clock upon getting root: voila, get out of jail free card.
I just scheduled a meeting for September 5th, 1752!
Chapter 1: Meet Sam
Chapter 1: Sam sets up NTP on Linux
Section1: Sam meets the man in the Red Hat: In this chapter Sam types rpm -i ntp.rpm && ntpd
Section2: Sam meets Mandrake: In this chapter Sam types urpmi ntp && ntpd
Section3: Sam meets Gentoo: In this chapter Sam types emerge ntp && ntpd
Section 4: Sam meets Debian and battles the GNU: In this chapter Sam types apt-get install ntp && ntpd
Chapter 2: Sam set up NTP on other Unixes
Section 1: In this chapter Sam meets puffy the blowfish and types pkg_add ntp.tgz && ntpd
Section 2: In this chaper Sam meets Beastie and types pkg_add ntp.tgz && ntpd
Section 3: In this chapter Sam battles his way to the Oracle at Solaris and types pkg_add ntp.tgz && ntpd
/* oops I accidentally made a comment, sorry */
I learned at timecube.com
I am sure I will be modded down, but what the heck....
;-)
UDP and TCP are part of TCP/IP. (Just a question of whether we are working on level 3-4 or 4-5 on our OSI model.)
Ummm.... TCP/IP and OSI were designed to be completely separate networking protocol suites. Ultimately, TCP/IP does not mesh well with the OSI model.
After the failure of anyone to actually impliment OSI, it became a great tool to confuse wannabe network techs.
For the record, TCP/IP was designed around (and runs on) a 4-layer model. This model (known as the DoD model) actually matches what is happening. Again, the OSI model would have matched what happened with the OSI protocol suite but such a suite was never fully implimented. Trying to fit 4 layers into 7 is a complete waste of time and only serves to confuse the subject.
UDP is pretty simple. It is just like a stripped down version of TCP which was designed as its name suggests for sending application-specified datagrams over a network (TCP handles the datagramming so you handle it as a stream).
The three major Transport Layer (DoD model) protocols in TCP/IP are TCP, UDP, and ICMP. There are others, like IGMP and other multicasting protocols, but these are not as major as those three.
Using the OSI model for describing TCP/IP is about like using the Ptolomeic model for describing planetary motions in that making it work requires needless complexity. Because it is not a simple solution (Occam's Razor: "One Should Not Needlessly Multiply Entities"), and making it work conceptually requires needless complexity, I am convinced that we should stop teaching the OSI model except in the History of Computer Networking
LedgerSMB: Open source Accounting/ERP
Comment removed based on user account deletion
RFC1180 says you're an idiot.
Actually, it says 'The generic term "TCP/IP" usually means anything and everything related to the specific protocols of TCP and IP. It can include other protocols, applications, and even the network medium. A sample of these protocols are: UDP, ARP, and ICMP. A sample of these applications are: TELNET, FTP, and rcp. A more accurate term is "internet technology". A network that uses internet technology is called an "internet".'
But I choose to rephrase that as "You're an idiot."
---
Mod me down, you fucking twits. Go ahead. I dare you.
(I read with sigs off.)
The three major Transport Layer (DoD model) protocols in TCP/IP are TCP, UDP, and ICMP. There are others, like IGMP and other multicasting protocols, but these are not as major as those three.
There are quite a few more than that.
Si vis pacem, para bellum
The only thing more annoying than a Libertarian is an (un|mis)informed Libertarian
I just keep track of the dupes on slashdot. When I see this story again, I'll know it's four hours later... ... give or take a month or two... :)
"Status of this Memo...This RFC is a tutorial on the TCP/IP protocol suite, focusing particularly on the steps in forwarding an IP datagram from source host to destination host through a router. It does not specify an Internet standard."
Note the specific and correct first use of "TCP/IP protocol suite." No proper name has ever been given to the entire suite of Internet protocols, so the need has been filled through the use of terms such as "TCP/IP based" or "Internet Protocol suite." Such terms are often simplifed to "TCP/IP" or "IP" for sake of brevity, at the expense of correctness, as is the case in RFC1180. Subsequent usage there is of an abbreviated form, suitable for a tutorial, although technically incorrect.
You're obviously unaware of the nature of RFCs. Historically, anyone could write anything and submit it as an RFC, correctness be damned. As RFC30 states: "The content of a NWG note may be any thought, suggestion, etc. related to the HOST software or other aspect of the network. Notes are encouraged to be timely rather than polished...These standards (or lack of them) are stated explicitly for two reasons. First, there is a tendency to view a written statement as ipso facto authoritative, and we hope to promote the exchange and discussion of considerably less than authoritative ideas." For you to base an argument on RFC1180 being somehow authoritative in regard to terminology simply demonstrates your lack of understanding of both RFCs and the reason for RFC1180, which is not to define terminology, but to describe the IP forwarding process.
If you examine the actual standards (i.e. STD5/RFC791/IP and STD7/RFC793/TCP) you will not find the terms used with such imprecision. Since the trigger for this thread branch is UDP, it's helpful to examine STD6/RFC768. It is clear from a reading that UDP works with IP, but is separate and distinct from TCP. UDP is no more a part of TCP/IP than is 802.3 Ethernet, although they're commonly used together.
I won't even call you an idiot, because you're obviously thinking, just ignorant of the facts.
I'll also point out that Internet is capitalized when used to refer to the global internet based on the IP suite of protocols. When not capitalized, it can refer to any network, not limited to those based on IP. IPX, Decnet, Appletalk, OSI suites of protocols can all be used to form internets.
"National Security is the chief cause of national insecurity." - Celine's First Law
If you think you might ever need to do that, better hope you're not using BSD syslog or that the intruders are kind enough not to do so during the wrong time window.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
That's because Score:42 isn't supported by Slashdot.
The Tao of math: The numbers you can count are not the real numbers.
...is how to stop it from listening on port 123/UDP. Any suggestions? And yes, I did read the fine manual.
I'm proud of my Northern Tibetian Heritage
I haven't read this book but I have read "Confessions". St Augustine in the late 5th Century wrote of the impreciseness of time, especially when defining the present. Actions remembered are past. Are they real? The present is immeasurable as it lies between the past and the future. The future does not exist and passes into the past which again does not exist but in memories and consequences of actions.
Perhaps the discrete quantisation of time by a computer clock and the act of recording logs at the time of events overcomes the issue? No, again the computer logs are recorded after the event. In the case of a disk log write, a very long time after the event (in the scale of the computer clock quanta). Lots of things can happen in that time to potentially change the record. Add in network logging and it is real ancient news.
Slashdot: Where nerds gather to pool their ignorance
That is hilarious. What adds to it is the fact that 7804 people have rated it, a childrens book, but only 104 people have rated the review right below it. :)
There are quite a few more than that.
I said there were others. But most of those on the IANA list are either internetwork or network access protocols tunnelled over IP (GRE, IP/IP, etc) or they are seldom-used transport layer protocols which are almost never used by applications. IGMP is the only real transport level protocol protocol which I did not list that could be argued to be major in that it is used by routers to rebuild routing tables, etc.
So how many real *transport* protocols are actually used?
LedgerSMB: Open source Accounting/ERP
Seriously though, the trades are littered with terminology that is WAY outdated and I swear is just out there to confuse the laymen. If you've ever studied electricty, our notion of + and - comes from Benjamin Franklin, and he had it backwards. In truth, the negative end of the circuit is where the electrons are coming from. The whole notion of Voltage is a bit confused (people think it's anything from speed to pressure. It's actually neighter.) And then when you start getting into alternating current, whoooohaa, watch the sparks fly literally.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
But when does Sam get to Mount Doom?
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
//Did you know that alternating current has a magentic component that you have to take into account when designing circuits to handle large motors and whatnot?
///And that magentic field is an imagionary number. There's complex math, and then there is Complex Math.
:-)
I was aware of that. I believe this is how crosstalk happenes on telephone lines (induced electric current due to magnetic fields from the alternating current component of the speach signal).
Brilliant. But Complex Math doesn't have to be that complex
LedgerSMB: Open source Accounting/ERP
Accurate time keeping is great in modern society for catching trains and making appointments (though I've had more success catching trains since my housemate set the microwave clock in the kitchen a couple of minutes fast). I suspect that overall we tend to be too uptight about time: for 99.5% of human history we've watched time pass with the sun, moon and seasons. If several Australian aboriginal tribes were having a council, the first to arrive would almost certainly have to wait a few days for the last to arrive, but this didn't bother them as presumably they had enjoyable or productive ways of filling in their time. In our modern society, we're often stuck with a long wait ahead and nothing to do.
I’m old enough to remember 16K of memory being described as “whopping”
He has to ask Al first, and Al will naturally have to ask Ziggy.
"No More Sloppy Seconds"
Once when I was in Hawaii, on the island of Kauai, I met a mysterious old stranger. He said he was about to die and wanted to tell someone about the treasure. I said, "Okay, as long as it's not a long story. Some of us have a plane to catch, you know." He stared telling his story, about the treasure and his life and all, and I thought: "This story isn't too long." But then, he kept going, and I started thinking, "Uh-oh, this story is getting long." But then the story was over, and I said to myself: "You know, that story wasn't too long after all." I forget what the story was about, but there was a good movie on the plane. It was a little long, though.
:-)
From Jack Handy