Slashdot Mirror
Researcher Runs IP Network Over Xylophones
joabj writes "Following up on experiments of running Internet Protocol(IP)-based networks with carrier pigeons or bongos, UofC grad student R. Stuart Geiger has demonstrated that it is possible to transmit simple ping requests across two computers using people playing xylophones. Throughput is roughly 1 baud, when the participants don't make any mistakes, or get bored and wander off. The OSI encapsulated model of networking makes this project doable, allowing humans to be inserted at Layer 1, the physical layer. Vint Cerf wasn't kidding when he used to say, 'IP on Everything.'"
I remember doing "networking via scraps of paper" at school.
Writing silly notes since kindergarten and then actually implementing some real protocol in computing classes.
Then a couple of years later an LED, a bit of fibre and an LDR and we were building "fibre networks".
Mind you, this was two decades ago.
Looking even at the "cool" projects which come out of MIT undergrads, I get the impression that almost all children are exposed to absolutely nothing interesting whatsoever before the age of 18.
Do we call Cal UofC? I had to check the article to make sure this very serious research project was coming out of California and not the University of Cambodia.
IP doesn't mean TCP/IP. The TCP half is what does the error control. Therefore, a ping wouldn't have error correction... just "appropriately replied/didn't reply appropriately"
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
Speilberg thought of communicating using musical notes 35 years ago
Error detection is a Layer 2 responsibility. TCP only does sequence numbers and resends lost packets.
Upcoming studies:
Improving Baud: Coffee vs Electroshocks
IP Backbone Implementation Using Michael J. Fox
River Rapids: High-Speed Internet With Riverdancers
Increasing Latency With Rube Goldberg Networks
Replacing LCD Screens With Bored College Students And Etch-a-Sketches
Stone-age Computing: Exploring Completely Inadequate Alternatives To Modern Technology
1 baud seems quite slow. Using the different notes to code diffent byte values would allow you to transmit data quite quickly. If you have 8 diffferent notes, then 2 consecutive notes can do 1.6 million different combinations. That's equivalent to 3 bytes. 2 notes could easily be played in 1 second rso 3 baud would be simple. Bring it up to 32 keys and the baud rate could go up quite highroad. You just have to encode it properly.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
So a quick Google turns up this Black-boxing the User: Internet Protocol over Xylophone Players (IPoXP)
Sigs. We don't need no steenking sigs.
I suggest we refer to this new protocol as "XoIP" (pronounced "zoip", of course).
Are YOU using the TOOL, or is the TOOL using YOU? Think about it!
Let's move the experiment in the subway.
Achille Talon
Hop!
Play major chords. If a note is incorrect then the chord is dissonant and you have an error condition.
Are YOU using the TOOL, or is the TOOL using YOU? Think about it!
Here's a mockup of what a noisy channel would sound like.
The article states that the musical instrument has "aluminum keys". From http://en.wikipedia.org/wiki/Glockenspiel :
"[A glockenspiel] is similar to the xylophone; however, the xylophone's bars are made of wood, while the glockenspiel's are metal plates or tubes, thus making it a metallophone."
Stuart Geiger has demonstrated that it is possible to transmit simple ping requests across two computers using people playing xylophones.
Was there ever any doubt that this could be done? It's the same as that carrier pigeon IP thing - it was always going to work. Has it taught us anything new?
systemd is Roko's Basilisk.
Baud is a measure of symbols per second, so it's meaningless unless the amount of information per symbol is defined.
In this case, it turns out that a symbol is a hexadecimal value, so the data rate is about 4 bits per second.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
With today's DSP technology, FFT algorithms, and a bank of solenoids, two computers could, in theory, transmit data via xylophones a LOT faster than one baud!
FFT analysis on the receiving ends determines which notes are being played and when, even simultaneously. By using notes unique to each machine, both can be playing and receiving simultaneously. It would be quite noisy, but would definitely work.
It would also be a good idea to "damp" the chimes, to dramatically reduce the audio decay rate. This would allow notes to be played in rapid succession, without losing the distinction between individual strikes of a given chime. Yes, the data throughput could become surprisingly fast without the PEBKAC! (Or in this case, PEBXAC)
Sounds like a cool project for someone with a bit of time on their hands, and a good pair of ear protectors.
Willie...
Nearly 9 years ago, ./ reported about IP over bongo drums already, featuring double the data rate.
http://slashdot.org/story/03/09/27/175242/tcpip-over-bongo-drums
As the original page is offlne since years, here's archive.org:
http://web.archive.org/web/20031230015730/http://eagle.auc.ca/~dreid/
What's next, VOIPOXP (Voice Over IP over xyloPhone? Latency will make satellite and lunar communication look really good. :-)
Nate
"The OSI encapsulated model of networking makes this project doable". The OSI model never made anything doable. Encapsulation was invented long before OSI came along and the seven layers never had any impact on the basic Internet protocols. The idea of "frameworks" is about as close as anyone got to anything like the OSI seven-layer cake which has always been an abomination and was never responsible for the development of anything.
"'IP on Everything." Sounds like his office is a really disgusting place.
War is one of the most horrible things a human can be exposed to. And one of the worlds largest industries.
PING doesn't mean IP. The most common form of PING doesn't use IP. It uses ICMP.
"National Security is the chief cause of national insecurity." - Celine's First Law
Not quite. In IPv4, both the network layer (IP) and transport layer (TCP) detect transmission errors via checksums. In IPv6, the network layer does not actually detect errors at all (I believe this is so in order to speed up routers by not having them calculate checksums). There's only the TCP checksum and whatever link-layer error detection you have protecting you from corrupted packets.
Score: i, Imaginary
Any layer may be implemented. The physical layer being a man and his xylophone, layer 2 could be a check that the notes are the correct ones. :-)
Layer 3, IP, needs a minimum of 160 bits for the header... and the guys need to be good in arithmetic calculation to provide an accurate checksum!
And why not a router at that layer, two men, one listens to the last xylophone and the other one translates to a piano in the next room... while there could be some networks interferences
Slashdot, fix the reply notifications... You won't get away with it...
"Ping"
"Your tits look nice today."
Replied very inappropriately!
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
RFC1149/2549 coupled to a keyboard under a line of birds?
Never ascribe to malice that which can adequately be explained by tenure.
In the public grade schools in Hawaii, the class will share about four textbooks on any given subject, and the state mandates and actually teaches toward state tests with state lesson plans and quizzes that are frequently wrong. They mark the kids as wrong when they get things right, and then tell them "you were right but I have to mark it lower because the state's answer is X."
And I don't mean normal smarter-than-the-test wrong, I mean things like singular v. plural.
Parenting is deficient in a lot of places, even abusive, but it's far from only parenting that is fucking up U.S. education.
-- IANAL, this isn't legal advice, and definitely isn't legal advice for you. Also, Squee!
Still uses IP. ICMP packets are delivered in IP packets.
Play major chords. If a note is incorrect then the chord is dissonant and you have an error condition.
or a sus4 chord :).
Every end has half a stick.
Here is the video demonstration that didn't get posted in the original article:
Video: http://youtu.be/qCT7SisWh38
Internet Protocol over Xylophone Players (IPoXP) situates humans at the lowest layers of the Internet. Read the full paper at http://www.stuartgeiger.com/ipoxp.pdf. A project by R. Stuart Geiger, Yoon Jeong, and Emily Manders at the University of California, Berkeley. Presented at alt.CHI 2012.
Really they didn't implement IP-over-xylophone -- you cannot, because there is no provision in the IP standard for framing between packets. They implemented some as-yet-undisclosed link layer protocol, and then ran IP over it. They could just as easily have run DECNET. Since they gave no details of the link layer protocol, we don't know if it had checksum support.
Someone had to do it.
And so did many other people to multiplex telegraph signals over precious telegraph lines. In fact generalizations of these techniques lead to the phonograph and telephone. Read Randall Stross Edison biography for details. He is a Silicon valley historian.
Just read the first review
A lot of people who've been working with electronic computers all their life intuitively assume that electrical computers are the only way to go, but there are other (albeit mostly currently impracticable) ways to automate binary math. -You can make a computer that uses water pressure instead of voltage- all the logic gates used in electronics can be built with copper pipe. -You could theoretically build a fully optical computer, with fibers, mirrors, beam splitters, etc (this I've been mulling over in my head) -Hell, I've heard of people using turtles for computing. Not quite sure how THAT would work, but party on, Wayne. Anyway we only use electrical computers because they're super easy to work with. That may change in the future.
You'll like this little gem better.
Except when a wrong note just yields a different major chord, like F major instead of C major.
That would require two notes to be wrong in order to end up with another major chord.
"Every man has a right to his own opinion, but no man has a right to be wrong in his facts." - Bernard Baruch
As a followon to my rfc1149 and rfc2549, I considered doing IP over black holes: if you carefully control matter being dropped into a black hole, you can modulate the huge X-ray emissions as the matter is ripped apart. This would be detectable over huge distances.
That is not correct. The IP header does have a checksum, but it covers only the header itself. Corrupted data would not be detected by the IP checksum. TCP has a checksum that covers the TCP header, all the payload data, and a few important fields of the IP header (such as source and destination IP).
That's correct. It also reduced the header size by two bytes. In total six bytes were removed from the part of the IP header before the addresses, but two new bytes were added as well, meaning an overall reduction from 12 to 8 bytes. The address part was quadrupled from 8 to 32 bytes.
Right. There are commonly error checking at the link layer below IP as well as in the transport layer on top of IP. And both of them will cover the IP header. It was considered redundant to have three separate layers compute checksums of the IP header, thus it was removed. It never covered anything but the header itself.
A few other changes were made at the same time to make up for the loss of the IP checksum. For UDP the checksum was made mandatory. It used to be optional, an IPv4 packet can carry UDP with a checksum of 0, and it will be considered valid for any data. Unlike UDP and TCP, the checksum in ICMP didn't cover any of the header bytes in IPv4. In IPv6 this was changed such that the ICMPv6 checksum also covers the IP addresses. If you for some reason don't like the fact that you are now being forced to checksum all data send over UDP, you can develop new applications using UDPlite. With UDPlite the checksum is mandatory, but it does not have to cover all the data. It covers the IP and UDP headers and as many of the data bytes as you like it to.
In the end those checksums are not really great. It turns out 16 bits of checksum is not enough to catch all the random errors that do occur. The probability that all 16 bits do by chance match when corruption happened is a bit too high. So in many cases you will make use of stronger checksums at a higher layer, in many cases even a cryptographic message-authentication-code. You can use MD5 at the TCP layer. At higher layers there are even more options.
Do you care about the security of your wireless mouse?
Also, there is something important to be said about link-layer error detection: it is not end-to-end. If corruption occurs while the packet is being handled by a router (as opposed to while it is traversing a link), the link-layer won't be able to detect it.
And one might point out the importance of always checking the IP headers end-to-end: it provides protection against misrouted packets caused by header corruption that passes undetected at the link layer. I suppose that's why the ICMPv6 checksum was changed to also include the IP header, as well as why even UDP-lite always checks the IP header, if anything else; they compensate for the missing header checksum in IPv6.
Yes, I would agree with that. Checksums were nice back when you didn't have that much computing power to waste on protocol overhead, but better error detection mechanisms are now feasible at a fraction of the cost. I do wonder, though, how many people actually use TCP-MD5 these days?
Thanks a lot for your reply!
Score: i, Imaginary
Very true. I have gotten into some verbal fights over that in the past with people insisting their error checking was good enough, and they didn't want to support the same kind of error checking other people were using. I kept pointing out, that the it was not a question about whether their error checking was good enough, but rather that they had to use the same as other people in order to get end-to-end checking.
In the end I backed down a little bit and instead insisted on having overlap, such that you'd compute the new checksum before verifying the old one, such that it was unlikely for a corruption to happen without affecting at least one of the checksum verifications.
I have gotten the impression it is used for most BGP sessions, and not much else. But I really wouldn't know since I haven't touched BGP directly. I have never used MD5 in TCP myself. Whenever I have needed better checks than what the default TCP checksum provided, I have always been using checks at a higher protocol layer.
Do you care about the security of your wireless mouse?