Sounds like the perfect solution to me. You don't need to know the actual latency. Instead as you increase your transmission speed an extra delay is added that your peer can tell you about, so you back off and speed up again with rules similar to TCP to try and stay near the sweet spot of your available bandwidth.
Just to be slightly more pedantic that the other responses. Bittorrent uses heaps of TCP streams, each of which can start pushing their current window size worth of packets when they receive an ACK packet from their peer. Assuming no other limits in the torrent client, this can easily flood your OS and router / ADSL / Cable modem's transmit buffers.
uTorrent and probably every other torrent client already needs to have complete control over the transmission speed of every TCP stream so it can impose a sane limit and avoid adding to the latency of your internet connection. And since TCP was being more of a hindrance anyway, the uTorrent team went off and designed a protocol based on sending individual UDP packets.
No it wasn't that new. But what is new is a common low level language representation that can be optimised in that form before being targetted to the different archetectures that are present in the same machine. It also helps that there is a single machine level daemon managing the tasks that run on those threads.
When TCP receives an ACK it can dump it's whole window size of packets onto the wire. A large number of TCP streams sharing a link with large transmit buffers and a small common bottleneck will saturate your transmit buffers. Yes TCP will tend to back off. But when you have heaps of streams all trying to transmit data, they collectively try to ramp up again too quickly.
I used to share an ADSL link with a neighbour of mine. I would often see the round trip latency over the ADLS link and back go up to 1 to 1.5 seconds with a bittorrent client running a bunch of TCP streams. So we put a hard upper limit on the transmit rate of his BSD router so the ADSL modem could never fill up its transmit buffer and most of the problem went away.
Seriously though, this is exactly what Apple have been working towards recently in the compiler space. You write your application and explicitly break up the algorythm into little tasks that can be executed in parallel. Using a syntax that is light weight and expressive. Then your compiler tool chain and runtime JIT manages the runtime threads and determines which processor is best equipped to run each task. It might run on the normal CPU, or it might run on the graphics card.
But you would need a plausible reason for finding that other evidence or your case would fall apart. Probably not difficult to manage but you would need to cover your back.
Even in windows 7 the sound interface sucks. I have a separate headphone and speakers audio device. But with the window sound api, each application needs to provide it's own configuration interface to choose which device the sound comes out of. And most applications don't bother to provide one and just use the default device making it impossible to select where the output goes individually.
Here's a few ideas off the top of my head as to why; There's been a rather concerted campaign of sharing spam, viruses and mallware on the public bittorrent trackers that may be effective at discouraging users. Bittorrent is probably slightly harder to classify, with it's encryption and random port numbers. There's a lot more people watching stuff on youtube these days. With big cheap portable hard drives becomming more common, a lot of people have gone back to sneakernet.
The system was mis-configured to generate too much X-ray energy. So any test that confirmed if the actual dose was the same as the configured dose would not have helped.
When we make the transition from CA signed certs to DNSSEC published public keys for web servers, we have a chance to redefine the url to do all of the above in one go;
s:tech.slashdot.org/story
I'm guessing we should use a different protocol name to support the differences in the way the key is obtained and verified, and we could provide a default port number along with the published public key in the DNS record.
You obviously have no idea about the early days of the internet and HTTP. The whole point of HTTP was to publish documents, if you host something you are implicitly allowing other people to fetch a copy of it.
robots.txt came about in the very early days of HTTP. An enterprising hacker wrote a crawler to index the whole internet (which wasn't that big at the time). But his crawler got stuck fetching pages from one machine with dynamically generated pages. This obviously tied up the bandwidth, CPU and disk IO of the server which annoyed it's owner. So the 2 people had a polite conversation via email and the opt-out robots.txt was invented.
My father has no hands (right arm at the albow, left arm about 3 inches below that) and drives an unmodified manual transmission just fine. But then this is in Australia. He had no trouble passing a driving test as a youth.
KeyserSosa
Thanks for this (and thanks aedes ). I'm going to steal his idea and post here as well.
We've fixed a couple of underlying bugs in markdown.py, and will write a blog post for those interested once the dust settles. We've also gone through and deleted the offending comments.
This exploit was a good old-fashioned worm, and its only purpose seems to have been to spread (and spread it did). The effect was limited to the site, and no user information was compromised.
A multiuser application I've worked on locked the entire client when you opened it. While a user had any client screen open, nobody else could modify any of the data on any of the 30 or so client related tables / screens. But then the application also had a kind of workflow system, so the client was assigned to one person to review anyway.
Ew, that's one of the worst things I found about the UI of IE7. If you accidentally touch the alt key, or you start to press an alt-something keyboard shortcut and change your mind, *everything* jumps around as the menubar jumps into existence.
If you want a menu bar to become visible, put it in front of something else that you aren't going to use at the same time. Making the whole UI of the application jump around and re-render is really annoying.
I dunno, I've showed a couple of managers the before and after versions and demonstrated just how easy it is to fix any further issues. I mean picture this "here's the old code" [scroll] [still scrolling] [*still* scrolling]. "I can't even begin to tell you where to look for [insert bug description]".
I don't usually touch the cruft in any significant way without an issue to fix though. If it aint broke, don't re-write the whole thing. But there are times where re-writing to work around a bug is quicker than trying to add another band-aid patch to the existing patchwork. And if your change is going to go through a couple layers of testing anyway...
Slashdot Mirror
Sounds like the perfect solution to me. You don't need to know the actual latency. Instead as you increase your transmission speed an extra delay is added that your peer can tell you about, so you back off and speed up again with rules similar to TCP to try and stay near the sweet spot of your available bandwidth.
Just to be slightly more pedantic that the other responses. Bittorrent uses heaps of TCP streams, each of which can start pushing their current window size worth of packets when they receive an ACK packet from their peer. Assuming no other limits in the torrent client, this can easily flood your OS and router / ADSL / Cable modem's transmit buffers.
uTorrent and probably every other torrent client already needs to have complete control over the transmission speed of every TCP stream so it can impose a sane limit and avoid adding to the latency of your internet connection. And since TCP was being more of a hindrance anyway, the uTorrent team went off and designed a protocol based on sending individual UDP packets.
Because they are standing on the shoulders of giants??
No it wasn't that new. But what is new is a common low level language representation that can be optimised in that form before being targetted to the different archetectures that are present in the same machine. It also helps that there is a single machine level daemon managing the tasks that run on those threads.
When TCP receives an ACK it can dump it's whole window size of packets onto the wire. A large number of TCP streams sharing a link with large transmit buffers and a small common bottleneck will saturate your transmit buffers. Yes TCP will tend to back off. But when you have heaps of streams all trying to transmit data, they collectively try to ramp up again too quickly.
I used to share an ADSL link with a neighbour of mine. I would often see the round trip latency over the ADLS link and back go up to 1 to 1.5 seconds with a bittorrent client running a bunch of TCP streams. So we put a hard upper limit on the transmit rate of his BSD router so the ADSL modem could never fill up its transmit buffer and most of the problem went away.
1. LLVM backend
2. Grand central
3. ???
4. Done.
Seriously though, this is exactly what Apple have been working towards recently in the compiler space. You write your application and explicitly break up the algorythm into little tasks that can be executed in parallel. Using a syntax that is light weight and expressive. Then your compiler tool chain and runtime JIT manages the runtime threads and determines which processor is best equipped to run each task. It might run on the normal CPU, or it might run on the graphics card.
Nah, there's just a nut loose on his keyboard.
But you would need a plausible reason for finding that other evidence or your case would fall apart. Probably not difficult to manage but you would need to cover your back.
Have you tried one of these?
Even in windows 7 the sound interface sucks. I have a separate headphone and speakers audio device. But with the window sound api, each application needs to provide it's own configuration interface to choose which device the sound comes out of. And most applications don't bother to provide one and just use the default device making it impossible to select where the output goes individually.
Richard Stallman does not cry into his beer. Microsoft cries into their beer. Richard Stallman cries into his speech.
Fixed that for you.
Here's a few ideas off the top of my head as to why; There's been a rather concerted campaign of sharing spam, viruses and mallware on the public bittorrent trackers that may be effective at discouraging users. Bittorrent is probably slightly harder to classify, with it's encryption and random port numbers. There's a lot more people watching stuff on youtube these days. With big cheap portable hard drives becomming more common, a lot of people have gone back to sneakernet.
Folding shirts? In japanese (I guess) no less?
The system was mis-configured to generate too much X-ray energy. So any test that confirmed if the actual dose was the same as the configured dose would not have helped.
When we make the transition from CA signed certs to DNSSEC published public keys for web servers, we have a chance to redefine the url to do all of the above in one go;
s:tech.slashdot.org/story
I'm guessing we should use a different protocol name to support the differences in the way the key is obtained and verified, and we could provide a default port number along with the published public key in the DNS record.
Company? what the...
You obviously have no idea about the early days of the internet and HTTP. The whole point of HTTP was to publish documents, if you host something you are implicitly allowing other people to fetch a copy of it.
robots.txt came about in the very early days of HTTP. An enterprising hacker wrote a crawler to index the whole internet (which wasn't that big at the time). But his crawler got stuck fetching pages from one machine with dynamically generated pages. This obviously tied up the bandwidth, CPU and disk IO of the server which annoyed it's owner. So the 2 people had a polite conversation via email and the opt-out robots.txt was invented.
My father has no hands (right arm at the albow, left arm about 3 inches below that) and drives an unmodified manual transmission just fine. But then this is in Australia. He had no trouble passing a driving test as a youth.
KeyserSosa Thanks for this (and thanks aedes ). I'm going to steal his idea and post here as well. We've fixed a couple of underlying bugs in markdown.py, and will write a blog post for those interested once the dust settles. We've also gone through and deleted the offending comments. This exploit was a good old-fashioned worm, and its only purpose seems to have been to spread (and spread it did). The effect was limited to the site, and no user information was compromised.
So obviously this is no longer spreading.
A multiuser application I've worked on locked the entire client when you opened it. While a user had any client screen open, nobody else could modify any of the data on any of the 30 or so client related tables / screens. But then the application also had a kind of workflow system, so the client was assigned to one person to review anyway.
Ew, that's one of the worst things I found about the UI of IE7. If you accidentally touch the alt key, or you start to press an alt-something keyboard shortcut and change your mind, *everything* jumps around as the menubar jumps into existence.
If you want a menu bar to become visible, put it in front of something else that you aren't going to use at the same time. Making the whole UI of the application jump around and re-render is really annoying.
cane toads, rabbits and blowflies in australia
Fixed that for you. And yes, biological measures have been tried with some success.
I dunno, I've showed a couple of managers the before and after versions and demonstrated just how easy it is to fix any further issues. I mean picture this "here's the old code" [scroll] [still scrolling] [*still* scrolling]. "I can't even begin to tell you where to look for [insert bug description]".
I don't usually touch the cruft in any significant way without an issue to fix though. If it aint broke, don't re-write the whole thing. But there are times where re-writing to work around a bug is quicker than trying to add another band-aid patch to the existing patchwork. And if your change is going to go through a couple layers of testing anyway...
The first one is not a normal mangled word. It's another word that could not be OCR'd but has already been identified by the crowd.
"First they came for the ...."
Along this vein I can highly recommend reading the works of Steve Keen. Who has been pointing out the flaws in "neoclassical" economics for years, and had no trouble predicting this economic collapse.