would it be possible to setup a server somewhere (probably collocated) and have your home network's router VPN into it? Then you could traffic shape both sides of the connection to your heart's content
Yes-ish. That would allow you to adjust the rates of the traffic in both directions, however the overhead added by the VPN tunnel would kill any efficiency gained.
Most VoIP connections use UDP or RTP, which is built on-top of UDP.
The theory here is that one can control the rate at which large downloads come in by controlling the rate at which we send ACKs which correspond to the incoming packets. The system doing the download sends the ACKs as fast as it can, as it's doing the best job possible of filling the bandwidth available. If our router were to delay some of these ACKs, the remote system will slow down its transmission, as it would interperate the router as network congestion.
Once we have a handle on incoming TCP connections flooding the pipe from our ISP, the UDP/RTP packets will flow much more efficiently.
Check that second link out; the sections on flow control and congestion control explain this much more succinctly than I can.
The key difference is that backscatter generating SMTP servers accept an email, close the connection with the remote server, realize that there is no local user by that name, and then generate a bounce e-mail (usually, but not always) with the content of the original message. As spammers usually put some unsuspecting third party's e-mail address as the "from" or "reply to", the third party gets the bounce, AKA backscatter.
The other approach is this: mailserver recieves inbound SMTP connection. When the initial chitchat between the mailservers gets to the part where the remote server lists the recipients, our mailserver recognizes that there is no local e-mail address by that name, and promptly rejects the mail. If the remote mailserver is legitimate, it will then generate a bounce itself, which will go to the (hopefully authenticated) person who sent the e-mail. If the remote mail server is a spam bot, it will just go on to the next target in its list.
So, from a backscatter prevention angle, it's better to reject an e-mail that will cause a bounce at the time of the original SMTP connection, instead of accepting it and then generating a bounce locally at a later time.
This is correct, however, I believe that it is not directly related to the thread at hand.
For example, suppose that you, Bob, and I share the same ISP. We all pay for 10 megabit download rates, and our ISP, in their usual over-subscribe-the-bandwidth approach, has delivered a total of 20 megabits to the router that services our connections.
Now, Bob and I fire up bit-torrent and queue up 20 GB of Battlestar Galactica for download. We both saturate our 10 megabit connections, using all 20 megabits of bandwidth available to our common ISP router. Then you open Skype, or pick up the handset on your VoIP phone, or launch some network action on Quake 15: Giblets and Chunks Edition.
No matter what you do, Bob and I are already consuming all of the bandwidth. In fact, there's probably a queue of packets as long as your arm @ the ISP's router waiting for delivery to Bob or myself. Your inbound, smaller, fewer, and significantly more time sensitive packets must wait in that queue before you get them. Instant choppy voice, slideshow video framerates, and high ping. In this case, there is nothing at all that you can do to correct your lag; you are at the mercy of Bob and myself.
That would indeed fix the problem for the moment, but try to think like a chess player on this one - what would their next move be?
Myself, I would identify the legitimate traffic, and force the P2P apps to imitate it. For example, if priority was given to SIP traffic on port 5060, I would ensure that the P2P app started to operate with port 5060 in order to try and fool the traffic prioritizer.
So, what would the appropriate response from the admin side be?
I once worked for one of the big 2 PC manufacturers in technical support. There was a documented case of a customer who had spilt lots of liquid inside his desktop system, and decided he needed to dry it out. His solution: take the components out, spread them evenly on an oven rack, and bake for a while.
As I understand it, the call came in because it wouldn't work when he put it all back together. It didn't work, of course...
So, sometimes computers do indeed need to be able to survive ovens.
Everyone has the following fundamental freedoms: ...
b) freedom of thought, belief, opinion and expression, including freedom of the press and other media of communication;
Is it not possible to consider that one "other media of communication" would be communication that occurs online, for example a blog, e-mail, slashdot postings, etc?
As I understand it, denying someone the right to print an article, or to have an article published, would contravene this section of the Charter (discussion about the right for a private party to refuse to publish someone elses article notwithstanding). Thus, I believe that it would be difficult to implement something like this as a law.
Now, I could see an ISP having a list of disenfranchised users, and possibly (although I would be disgusted by it) the ability for ISPs to share the lists of these people between each other. For a similar example that already exists, look at the requirements that many bars in Edmonton and Vancouver have for scanning your drivers license before you are allowed in. This system checks against a shared database that confirms you aren't listed as a "troublemaker" (AKA haven't been blackballed). The logic behind this system might be simple enough to apply to a shared blacklist at ISPs.
We all know that ironyblind people can see irony correctly underwater while those who have correct perception cannot.
I've never heard that before. My understanding is that ironyblindness is due to an absence or shortage of irony receptor cells in the brain. I don't see how that could give someone better comprehension underwater.
OTOH, I have heard that irony blind people are worse at spotting camouflaged humor. I presume that's because they percieve things DIFFERENTLY than the non-ironyblind person who created the camouflage.
I can see XKCD covering this one. My preference though would be the Flight of the Bumblebee. It would probably require more co-ordination amongst drivers than is possible in North America tho...
Well, it's not so much that his GPS is out. I expect that he's just getting preparing to move shop to the south pole. With global warming melting his ice/land, he'll need something more solid to operate from.
Plus I hear that the elves have unionized, and penguines are still willing to work for herring.
Slashdot Mirror
So then what if someone combines it with one of the phishing tactics that present "western" characters from an Asian character set in the address bar?
The address bar will still read correctly, but the values of the letters you see would be completely different from where you actually were.
Or am I way off base?
+1 Bingo! indeed!
I need that (and your .sig) on a t-shirt!
Oddly enough, there is an Ontario, CA. That's where they make maglites.
Meals Rejected by Ethiopia, or so I've heard.
Yes-ish. That would allow you to adjust the rates of the traffic in both directions, however the overhead added by the VPN tunnel would kill any efficiency gained.
Most VoIP connections use UDP or RTP, which is built on-top of UDP.
The theory here is that one can control the rate at which large downloads come in by controlling the rate at which we send ACKs which correspond to the incoming packets. The system doing the download sends the ACKs as fast as it can, as it's doing the best job possible of filling the bandwidth available. If our router were to delay some of these ACKs, the remote system will slow down its transmission, as it would interperate the router as network congestion.
Once we have a handle on incoming TCP connections flooding the pipe from our ISP, the UDP/RTP packets will flow much more efficiently.
Check that second link out; the sections on flow control and congestion control explain this much more succinctly than I can.
A fish, no?
Okiedokie, time to add my $0.02 to the pot :-D
The key difference is that backscatter generating SMTP servers accept an email, close the connection with the remote server, realize that there is no local user by that name, and then generate a bounce e-mail (usually, but not always) with the content of the original message. As spammers usually put some unsuspecting third party's e-mail address as the "from" or "reply to", the third party gets the bounce, AKA backscatter.
The other approach is this: mailserver recieves inbound SMTP connection. When the initial chitchat between the mailservers gets to the part where the remote server lists the recipients, our mailserver recognizes that there is no local e-mail address by that name, and promptly rejects the mail. If the remote mailserver is legitimate, it will then generate a bounce itself, which will go to the (hopefully authenticated) person who sent the e-mail. If the remote mail server is a spam bot, it will just go on to the next target in its list.
So, from a backscatter prevention angle, it's better to reject an e-mail that will cause a bounce at the time of the original SMTP connection, instead of accepting it and then generating a bounce locally at a later time.
This is correct, however, I believe that it is not directly related to the thread at hand.
For example, suppose that you, Bob, and I share the same ISP. We all pay for 10 megabit download rates, and our ISP, in their usual over-subscribe-the-bandwidth approach, has delivered a total of 20 megabits to the router that services our connections.
Now, Bob and I fire up bit-torrent and queue up 20 GB of Battlestar Galactica for download. We both saturate our 10 megabit connections, using all 20 megabits of bandwidth available to our common ISP router. Then you open Skype, or pick up the handset on your VoIP phone, or launch some network action on Quake 15: Giblets and Chunks Edition.
No matter what you do, Bob and I are already consuming all of the bandwidth. In fact, there's probably a queue of packets as long as your arm @ the ISP's router waiting for delivery to Bob or myself. Your inbound, smaller, fewer, and significantly more time sensitive packets must wait in that queue before you get them. Instant choppy voice, slideshow video framerates, and high ping. In this case, there is nothing at all that you can do to correct your lag; you are at the mercy of Bob and myself.
That would indeed fix the problem for the moment, but try to think like a chess player on this one - what would their next move be?
Myself, I would identify the legitimate traffic, and force the P2P apps to imitate it. For example, if priority was given to SIP traffic on port 5060, I would ensure that the P2P app started to operate with port 5060 in order to try and fool the traffic prioritizer.
So, what would the appropriate response from the admin side be?
OK, you asked for it.
I once worked for one of the big 2 PC manufacturers in technical support. There was a documented case of a customer who had spilt lots of liquid inside his desktop system, and decided he needed to dry it out. His solution: take the components out, spread them evenly on an oven rack, and bake for a while.
As I understand it, the call came in because it wouldn't work when he put it all back together. It didn't work, of course...
So, sometimes computers do indeed need to be able to survive ovens.
Perhaps we could get them both to jump off of Peter Mann's Bridge?
(With apologies to Rick Mercer)
As I understand it, denying someone the right to print an article, or to have an article published, would contravene this section of the Charter (discussion about the right for a private party to refuse to publish someone elses article notwithstanding). Thus, I believe that it would be difficult to implement something like this as a law.
Now, I could see an ISP having a list of disenfranchised users, and possibly (although I would be disgusted by it) the ability for ISPs to share the lists of these people between each other. For a similar example that already exists, look at the requirements that many bars in Edmonton and Vancouver have for scanning your drivers license before you are allowed in. This system checks against a shared database that confirms you aren't listed as a "troublemaker" (AKA haven't been blackballed). The logic behind this system might be simple enough to apply to a shared blacklist at ISPs.
I know that the Pentax K10D can shoot DNG natively - I own one. For discussion online, linky.
Animals merely have cell membranes.
Plants and such have both cell membranes and cell walls.
Source: wikipedia.
In my case, it recursed, and included
No, that's not quite right... That's better.
To mitigate that same problem, I wrapped my iptables shell script with a "sleep 30" and "iptables -F" commands. Live and learn, right? :-D
Hmm... I did that once, back in 2000 or 2001 somewhere. Fortunately I had console access to the firewall at the time.
.*
The only question is, can anyone top:
/var/www/tmp# rm -rf
that was around the same time.
There's something to be said for the school of hard-knocks way. I'm not yet sure what it is, but someday I'll figgure it out.
Kompressor
Hmm... Is it something like one of these?
Well, if you cross over to the oncoming lane, you'll hear The Devil! Right before you plow head-on into a Mack truck, of course...
I can see XKCD covering this one.
My preference though would be the Flight of the Bumblebee. It would probably require more co-ordination amongst drivers than is possible in North America tho...
Kompressor
Hey hey hey....
;-)
Some of us have standards around here
Kompressor
Well, it's not so much that his GPS is out. I expect that he's just getting preparing to move shop to the south pole. With global warming melting his ice/land, he'll need something more solid to operate from. Plus I hear that the elves have unionized, and penguines are still willing to work for herring.