Small typo: "No, because you need to upload all the routes, in fact you will upload no routes" should be "No, because you need NOT to upload all the routes, in fact you will upload no routes".
"it's all stateless" - no not exactly. First OpenFlow has counters and flow rules can apply to those counters. You can use this to rate limit flows or you can use it to sample packets (copy every 500th packet etc). Or to load balance.
But most important, the whole point of OpenFlow is that you do not upload the whole set of rules to the switch. Indeed the actual rules might be too complex for the switch to hold or to compute.
Take the BGP implemented by RouteFlow as an example. The global BGP table has about half a million routes. Your cheap OpenFlow enabled switch might not be able to hold half a million OpenFlow rules. Is all lost? No, because you need to upload all the routes, in fact you will upload no routes. Instead the first time the switch has a IP packet with a new destination, it will ask the controller. The controller will consult the BGP tables and program the switch with a new rule. Now the switch knows how to deliver for this destination. In the process the switch might need to flush an older rule to make space for the new rule in memory. This is made possible by the before mentioned counters - there are also timers. So we can remove the least used rule and avoid removing any recently active rules.
OpenFlow turns cheap switches into advanced devices that can solve many tasks that before required expensive equipment. The cheap switch can become your BGP border router. It can be your HTTP load balancer. It can be your carrier NAT device. It can support the full range of protocols even if the maker did bother to implement them in firmware.
There is no routing as such. For each new "flow" the switch needs to ask a computer (controller) what to do. The controller will then program the switch with instructions for the new flow.
You claim that the flow table is just a glorified routing table. Maybe it is but much more fine grained, you can match on any fields in the IP packets, including layer 2 and 3 such as MAC, IP, port numbers, IP TCP packet types (syn packets) etc. Also you can mangle the packets, for example modify the MAC or IP address before forwarding the packet.
With this you can build some amazing things. The switch can be really dumb and yet it can do full BGP routing: RouteFlow: https://sites.google.com/site/routeflow/
The other canonical use case is virtualisation. No it will not be rerouting physical cables. But it can pretend to do so. Combine it with VMs you can have a virtual network that can change at any time. If you migrate a VM to another location, the network will automatically adapt. And still the switches are dumb. All the magic is in the controllers.
Before OpenFlow you would need to make a vlan (or MPLS). When moving the VM to a new location, you would need to reconfigure a number of switches to pass around this vlan and there is no standard protocol to do so.
OpenVSwitch supports OpenFlow so you can pretend your virtual network with virtual switches includes the VM host itself: http://openvswitch.org/
Compare it to the alternative such as the good old spanning tree protocol. You have a number of independent agents who together have to decide how to react to a fault. This is complex and requires clever algorithms that can deal with timing issues and what not.
With a centralised controller the problem is much easier. One program running on one CPU decides how to reconfigure the network. This can be faster and possibly find a better solution.
Of course you need redundant controllers and redundant paths to the controllers. Apparently Google decided you need a controller per location.
There is nothing theoretical about it. There are 111 turbines and each will produce 3.6 MW. Multiply those two numbers and you get 400 MW.
Anholt will produce power in wind speeds between 2 m/s and 25 m/s. Above 25 m/s the turbines will be stopped to protect them from damage. Yes, that happens once or twice a year around here.
But notice that full power is archived already at 13 m/s wind speed. This means the wind farm quite often will be producing at the full output of 400 MW.
Anholt may not be finished yet, but it is not exactly the first offshore wind farm around here. We got two 200 MW offshore wind farms already. What remains to be seen is the so called capacity factor rating. How much energy will be produced on average? The 200 MW offshore wind farms have a capacity factor of 43% meaning they are on average producing 86 MW. Sometimes they will do 0 when there is no wind and often they will do 200 MW - average that and you get the 86 MW. Anholt is expected to get similar numbers.
The original article did not say average power produced. They said generating power. But even if they had been calculating the average power they would still be wrong. Anholt will produce at least 160 MW on average, more than the larger estimate of a 100 square kilometre farm, and it is smaller than that. Anholt is in fact doing twice the larger estimate if you go by average and almost five times their estimate if you go by generating power.
It seems to me that if you do a study, it would be wise to look at what is already out there in the real world!
Rubbish, a 3 MW wind turbine will take less than 25 square metres at the base. The rest you can use for farming.
That is 120.000 watts per square metre used land. In other words the land use is negligible if the turbine is placed on farm land. This is of course also true of it is place offshore.
For this reason wind turbines can be quite popular for farmers. It is extra income from their land.
Just don't place them anywhere near people. You do not want to live next to one of these things. You want at least a few kilometres distance.
Those pictures of wind farms in California are interesting. Compare to pictures of danish wind farms
Totally different strategy.
However I would like to believe that neither american nor danish engineers are idiots. The windmills are likely placed in the most optimal way according to the landscape and economics.
Maybe Keith is owned by big oil. Because this "prediction" is already way surpassed by reality.
The study claims that large installations of more than 100 square kilometres will only produce between 0.5 and 1 watt per square meter. In other words, the claim is that a 100 square kilometre wind farm will only have a generating capacity between 50 MW and 100 MW.
But how does that fit with the fact that Denmarks largest wind farm, the Anholt sea based wind farm, has a generating capacity of 400 MW and it only covers 88 square kilometres?
But I also noticed, he spent a lot of time and effort 'breaking the rules' to make Java better, and working to make it more efficient, but he didn't do that for C#.
It is clear that he is a Java novice and he admits so much. He failed to do it right, both his version of HttpServer and his ServerSocket are WRONG.
HttpServer needs to be configured with a thread pool. If you fail to do that, it will run single threaded. And it is clear that is exactly what happened.
ServerSocket is the old network API from the first version of Java. It was build with the idea of "one thread for each connection". Therefore all IO calls are blocking because you are supposed to run them in threads. ServerSocket has an accept call that will block until the next connection. You are then supposed to start a new thread (or use a thread pool) and let the new thread handle the new connection. He clearly failed to do that, instead he made a single threaded implementation.
Modern Java frameworks use NIO - the new network IO for Java. This has non-blocking IO calls and allows much faster processing. It is also much harder to use on a low level, which is why most developers never do that.
All of this explains why he is suddenly having much more luck when he switches to Tomcat. This takes him away from the low level stuff that he is doing wrong. Tomcat will do the IO correctly, it will use threads. It will AFAIK not use NIO however. But just doing it right using threads will give him a speed up of order of magnitudes.
Conclusion: He was not spending a lot of time and effort on making Java better. He was trying to learn Java. Too bad that he failed. Great that he moved on to easier higher level Java.
It is at least 10 times faster and the only likely difference between mine and the original author is that I am using the Java IO framework correctly. I will hand of new connections to a connection pool while he incorrectly runs it all in one thread. His is just wrong.
...and even when the Java version has a level of abstraction removed and returns a hardcoded header string, the C# version (keeping it's higher abstraction level) still beats it.
The Java version is wrong. When you fix it, it is order of magnitudes better. I have no idea if the C# version was wrong too but it wouldn't surprise anyone. The test is rubbish.
He admits to be java novice and he made a novice mistake: The Java IO framework is blocking and was constructed so you would have one thread per connection. He failed to do that. He made it single threaded - and that is just wrong. Apart from making the thing slow as a turtle, it would never work in a real application. One hung connection would make his whole server stuck.
This is a 32 line Scala program. Yes Scala instead of Java but it is based on the exact same SocketServer that the author claims his program uses. It will sit there and listen for a connection, then do a simple imitation of HTTP. It even optionally supports HTTP Keep Alive.
baldur@neaira:~/tmp$ ab -c 4 -t 10 -n 1000000 http://localhost:5555/ Time taken for tests: 10.000 seconds Complete requests: 136991 Requests per second: 13698.99 [#/sec] (mean)
So about 13,000 requests per second processed on my old laptop. The author did 2000 requests in 2687 ms = 1344 requests per second or about 10 times slower than my program.
Lets try again with Keep Alive enabled:
baldur@neaira:~/tmp$ ab -c 4 -t 10 -n 1000000 -k http://localhost:5555/ Time taken for tests: 10.000 seconds Complete requests: 692424 Requests per second: 69242.23 [#/sec] (mean)
So now we are doing 69.000 requests per second or 50 times faster than the authors program.
It might be that my old laptop is 10 or 50 times faster than the setup the author uses. But somehow I do really not think that is it. I think it is extremely likely that the author is a.NET programmer that has insufficient knowledge of Java to code this simple test correctly and that his program is simply wrong. More specifically I suspect that he did not know that you need to use a thread pool to process the connections, or if he did use one, that he used it wrong.
A stateless NAT should be lot easier on the machine than a firewall
Assuming that by NAT we mean the port address translation variety implemented by home gateways, there is no such thing as stateless NAT. For each inbound packet received from the ISP, the NAT device needs to know which of your internal machines is the intended recipient. It does so by looking up a relation in a table (external host IP, external host port, gateway port) -> (internal host IP, internal host port). This table is updated on outbound packets. If a relation is missing on inbound packets the gateway has no way of knowing where to send the packet and so has to drop it. It is from that property that a NAT device can act as a primitive stateful firewall.
Now some (=most home gateways) NAT devices cheat a little on that mapping (full cone NAT). Instead of recording the full relation as above, they record a reduced set of information. This makes them less secure, because a third party might be able to pass packets. Many NAT traversal techniques depends on the NAT device to "cheat" like this.
Notice that even the cheating devices are not stateless. Also note that a firewall could do the same tricks. It would become less secure in exact the same way as the NAT.
I am not sure why they bother cheating though. It does not really save any CPU power. The algorithm is only slightly less complex. They do save a little bit of memory as the tables will be smaller.
I should also mention there is a RFC that requires customer routers to support IPv6 firewalling and to have it enabled by default: http://tools.ietf.org/html/rfc6204
NAT is harder than firewalling. Both requires the same connection tracking. But only NAT requires rewritting the packets. If your router is handling NAT it will do IPv6 firewalling as well.
Whats the worm traffic (ssh and other) on the IPv6 internet? The weird IPv6 people want us to just hop on IPv6 by tunneling under our old IPv4 firewall/routers. So how much parasitism and hacking is on the new network? And can we expect a wave of new attacks/exploits to happen to people who turn on IPv6 and blindly bypass the only protection they have?
Unlike IPv4, it is not practical to probe the IPv6 network blindly. You need to know the IP address of your target exactly. There is no guessing it.
A worm on IPv4 can send a packet to a random IPv4 address and have a high chance of that packet actually reaching someone. There are only about 4 billion IPv4 addresses. Even a single computer can send to every single IPv4 address in a span of only a few hours. If there are thousands of infected computers sending random packets, they got the IPv4 network covered in mere moments.
Fast forward to the IPv6 world. The IPv6 has an address space of 128 bits. This is the same size as strong encryption keys. Sending to a random address has zero chances of actually reaching anyone.
IPv6 addresses can be split into the first 64 bits called the prefix and the other half of 64 bits called the host identifier. Lets say you somehow learned the prefix of some user. But even if you only have to guess 64 bits of host identifier, the chances that you are going to hit his computer is so extremely low that we can call it zero.
What if you already know his full address? You wont for long. Most operative systems today have privacy extensions enabled. This is a system that makes your computer change the host identifier part of your address on a regularly basis (at least once per day).
People will still have routers and those will provide firewall services on IPv6. You would not get past that, but even if you did, you would not be able to simply guess an address. You can only send packets to people that recently sent packets to you first. Or which otherwise advertised the address through DNS or through a peer to peer network such as Bittorrent.
Bottom line: Classic worms and cold scanning is history on IPv6.
Luckily, IPv6-only connections are becoming less useless every day.
Yep. I love browsing Slashdot at home with my IPv6 conn... oh wait.
Yes you can. Check this:
baldur@neaira:~$ telnet 2001:778:0:ffff:64::216.34.181.45 80 Trying 2001:778:0:ffff:64:0:d822:b52d... Connected to 2001:778:0:ffff:64::216.34.181.45. Escape character is '^]'. GET / HTTP/1.0
HTTP/1.1 301 Moved Permanently Server: Apache/2.2.3 (CentOS) Location: http://slashdot.org/
Although due to that redirect you will have to put the IPv6 address for slashdot.org into your/etc/hosts file. Or you could use 2001:778::37 as your DNS server:
slashdot.org has address 216.34.181.45 slashdot.org has IPv6 address 2001:778:0:ffff:64:0:d822:b52d slashdot.org mail is handled by 10 mx.sourceforge.net.
This is called NAT64 and is admittedly not much better than carrier grade NAT. But it allows you to run pure IPv6 and still have access to the IPv4 internet.
The applet exploits a buffer overflow which existed in processing malformed images or audio files and affects Sun Java SE in JDK and JRE 5.0 before Update 22 and JDK and JRE 6 before Update 17. The applet exports Java class "vmain" with several member functions named "HB", "HexDecode", "mspray" and "paint". The member function "mspray" crafts an image in memory which is than passed to the "paint" function.
The "paint" function then calls "drawImage" from the standard AWT Java library causing a buffer overflow and potentially executing code from the memory allocated by the "mspray" function.
Yes the point is that you can make it "later" instead of "sooner". Example of this is the Google Native Client which exposes OS services through only an API consisting of a handful of allowed methods compared to the thousands of the Java platform. It is a lot easier to make 10 methods secure than 1000.
Native Client can run C code inside the Sandbox, so you can still take advantage of existing libraries.
Java code is sandboxed but many parts of the Java standard library is not written in Java. Every time SUN took the easy way out and used an external library instead of reimplementing in Java, they opened the platform to exploits of bugs in that library. Also it seems the SUN engineers did not really like to code in Java so they made a very large part of the platform in C - even when they could have made those parts in Java.
The standard library rt.jar file has more than 1000 methods that are implemented by native calls to C code or third party C libraries. It is simply too much to check that every single one of those crossed all the t's and dotted the i's. So we keep finding more bugs.
The sandbox itself is fairly secure so there is nothing wrong with the idea. It is just the implementation that went wrong.
You already know the location of the satellites without receiving anything at all from the satellites. The orbits are well known and downloaded into your GPS device. The satellites themselves have no way of knowing their own position, they only know the same data as was downloaded into your GPS. The only principal information from the satellite is the timing of the signal. The signal also tells you the time of the day with a precision of 1 second, but you hardly need an atomic clock to know that already.
Your basic misunderstanding of the system is that you believe you that you have 3 points. But the only thing you actually got is the timing of the relative delay of reception of three signals which gives you two values to work with. From these two values you have to calculate your position and no magical tricks can somehow infer three points from 2 values.
You seem to assume that you somehow know the distances to 3 satellites. But you don't. What you got is three time-signals. From that you can only infer two distances. Two is only enough for a 2D-fix.
That is what people have been trying to tell you. You need one satellite to be your time-fix.
The satellites will all send out a signal at exactly the same time. Because of the speed of light you will receive each signal slightly delayed and with a different delay for each satellite. When you receive the first signal you start your clock. You then measure time until you receive the second signal and then the third signal. It should be fairly obvious that you by this method only end up with TWO values from THREE satellites.
IF you did carry around your own atomic clock you could in theory be your own time fix. You would know _exactly_ when the satellites are going to broadcast their signal so you could start your timing clock before receiving any signal.
Atomic clocks are however big as a fridge, so nobody actually does this, not even the military.
That is for the insurance companies to figure out. If they can't, they will pay half each. Or they will sue each other. You wont care because your insurance wont go up since it wasn't your fault either way.
There is no problem here. It is not even any different from having a car today. What if your car has a fault that makes it accelerate unexpectedly and crash into someone (Toyota!)? The answer is your insurance will pay, then they will sue Toyota for the damages.
Load balancing/failover between different ISPs: IPv6 - ISP cooperation and 1300EUR/year, IPv4 - NAT router with software that supports this (for example pfsense) - can be completely free and does not need ISP cooperation or knowledge.
You got that one wrong. It is like this:
IPv6 - It just works, no extra software needed, no configuration or NAT router needed. No support or cooperation from either ISP needed.
With IPv6 you just order internet from multiple ISPs. You get a router from each. You connect said routers to your network. And you are done. If one router goes down or if the link or ISP goes down, all traffic will automatically move on to the other available options within a failover period of 30 seconds.
It is true that there will be no load balancing as such, only failover and not much in the way of configuring anything. In the larger picture, this will however make dual ISP an option for a lot of people that would never have figured out how to setup pfsense. My mom could do it.
Slashdot Mirror
Small typo: "No, because you need to upload all the routes, in fact you will upload no routes" should be "No, because you need NOT to upload all the routes, in fact you will upload no routes".
"it's all stateless" - no not exactly. First OpenFlow has counters and flow rules can apply to those counters. You can use this to rate limit flows or you can use it to sample packets (copy every 500th packet etc). Or to load balance.
But most important, the whole point of OpenFlow is that you do not upload the whole set of rules to the switch. Indeed the actual rules might be too complex for the switch to hold or to compute.
Take the BGP implemented by RouteFlow as an example. The global BGP table has about half a million routes. Your cheap OpenFlow enabled switch might not be able to hold half a million OpenFlow rules. Is all lost? No, because you need to upload all the routes, in fact you will upload no routes. Instead the first time the switch has a IP packet with a new destination, it will ask the controller. The controller will consult the BGP tables and program the switch with a new rule. Now the switch knows how to deliver for this destination. In the process the switch might need to flush an older rule to make space for the new rule in memory. This is made possible by the before mentioned counters - there are also timers. So we can remove the least used rule and avoid removing any recently active rules.
OpenFlow turns cheap switches into advanced devices that can solve many tasks that before required expensive equipment. The cheap switch can become your BGP border router. It can be your HTTP load balancer. It can be your carrier NAT device. It can support the full range of protocols even if the maker did bother to implement them in firmware.
There is no routing as such. For each new "flow" the switch needs to ask a computer (controller) what to do. The controller will then program the switch with instructions for the new flow.
You claim that the flow table is just a glorified routing table. Maybe it is but much more fine grained, you can match on any fields in the IP packets, including layer 2 and 3 such as MAC, IP, port numbers, IP TCP packet types (syn packets) etc. Also you can mangle the packets, for example modify the MAC or IP address before forwarding the packet.
With this you can build some amazing things. The switch can be really dumb and yet it can do full BGP routing: RouteFlow: https://sites.google.com/site/routeflow/
The other canonical use case is virtualisation. No it will not be rerouting physical cables. But it can pretend to do so. Combine it with VMs you can have a virtual network that can change at any time. If you migrate a VM to another location, the network will automatically adapt. And still the switches are dumb. All the magic is in the controllers.
Before OpenFlow you would need to make a vlan (or MPLS). When moving the VM to a new location, you would need to reconfigure a number of switches to pass around this vlan and there is no standard protocol to do so.
OpenVSwitch supports OpenFlow so you can pretend your virtual network with virtual switches includes the VM host itself: http://openvswitch.org/
Compare it to the alternative such as the good old spanning tree protocol. You have a number of independent agents who together have to decide how to react to a fault. This is complex and requires clever algorithms that can deal with timing issues and what not.
With a centralised controller the problem is much easier. One program running on one CPU decides how to reconfigure the network. This can be faster and possibly find a better solution.
Of course you need redundant controllers and redundant paths to the controllers. Apparently Google decided you need a controller per location.
There is nothing theoretical about it. There are 111 turbines and each will produce 3.6 MW. Multiply those two numbers and you get 400 MW.
Anholt will produce power in wind speeds between 2 m/s and 25 m/s. Above 25 m/s the turbines will be stopped to protect them from damage. Yes, that happens once or twice a year around here.
But notice that full power is archived already at 13 m/s wind speed. This means the wind farm quite often will be producing at the full output of 400 MW.
Anholt may not be finished yet, but it is not exactly the first offshore wind farm around here. We got two 200 MW offshore wind farms already. What remains to be seen is the so called capacity factor rating. How much energy will be produced on average? The 200 MW offshore wind farms have a capacity factor of 43% meaning they are on average producing 86 MW. Sometimes they will do 0 when there is no wind and often they will do 200 MW - average that and you get the 86 MW. Anholt is expected to get similar numbers.
The original article did not say average power produced. They said generating power. But even if they had been calculating the average power they would still be wrong. Anholt will produce at least 160 MW on average, more than the larger estimate of a 100 square kilometre farm, and it is smaller than that. Anholt is in fact doing twice the larger estimate if you go by average and almost five times their estimate if you go by generating power.
It seems to me that if you do a study, it would be wise to look at what is already out there in the real world!
Rubbish, a 3 MW wind turbine will take less than 25 square metres at the base. The rest you can use for farming.
That is 120.000 watts per square metre used land. In other words the land use is negligible if the turbine is placed on farm land. This is of course also true of it is place offshore.
For this reason wind turbines can be quite popular for farmers. It is extra income from their land.
Just don't place them anywhere near people. You do not want to live next to one of these things. You want at least a few kilometres distance.
Those pictures of wind farms in California are interesting. Compare to pictures of danish wind farms
Totally different strategy.
However I would like to believe that neither american nor danish engineers are idiots. The windmills are likely placed in the most optimal way according to the landscape and economics.
Maybe Keith is owned by big oil. Because this "prediction" is already way surpassed by reality.
The study claims that large installations of more than 100 square kilometres will only produce between 0.5 and 1 watt per square meter. In other words, the claim is that a 100 square kilometre wind farm will only have a generating capacity between 50 MW and 100 MW.
But how does that fit with the fact that Denmarks largest wind farm, the Anholt sea based wind farm, has a generating capacity of 400 MW and it only covers 88 square kilometres?
http://www.dongenergy.com/anholt/da/projektet1/saadan_opfoeres_parken/pages/faktaomanholthavmoellepark.aspx (in danish sorry, use Google Translate).
But I also noticed, he spent a lot of time and effort 'breaking the rules' to make Java better, and working to make it more efficient, but he didn't do that for C#.
It is clear that he is a Java novice and he admits so much. He failed to do it right, both his version of HttpServer and his ServerSocket are WRONG.
HttpServer needs to be configured with a thread pool. If you fail to do that, it will run single threaded. And it is clear that is exactly what happened.
ServerSocket is the old network API from the first version of Java. It was build with the idea of "one thread for each connection". Therefore all IO calls are blocking because you are supposed to run them in threads. ServerSocket has an accept call that will block until the next connection. You are then supposed to start a new thread (or use a thread pool) and let the new thread handle the new connection. He clearly failed to do that, instead he made a single threaded implementation.
Modern Java frameworks use NIO - the new network IO for Java. This has non-blocking IO calls and allows much faster processing. It is also much harder to use on a low level, which is why most developers never do that.
All of this explains why he is suddenly having much more luck when he switches to Tomcat. This takes him away from the low level stuff that he is doing wrong. Tomcat will do the IO correctly, it will use threads. It will AFAIK not use NIO however. But just doing it right using threads will give him a speed up of order of magnitudes.
Conclusion: He was not spending a lot of time and effort on making Java better. He was trying to learn Java. Too bad that he failed. Great that he moved on to easier higher level Java.
So, where are your benchmark tests?
Here is a fixed version of the test: http://pastebin.com/CkJB6h2K
It is at least 10 times faster and the only likely difference between mine and the original author is that I am using the Java IO framework correctly. I will hand of new connections to a connection pool while he incorrectly runs it all in one thread. His is just wrong.
...and even when the Java version has a level of abstraction removed and returns a hardcoded header string, the C# version (keeping it's higher abstraction level) still beats it.
The Java version is wrong. When you fix it, it is order of magnitudes better. I have no idea if the C# version was wrong too but it wouldn't surprise anyone. The test is rubbish.
He admits to be java novice and he made a novice mistake: The Java IO framework is blocking and was constructed so you would have one thread per connection. He failed to do that. He made it single threaded - and that is just wrong. Apart from making the thing slow as a turtle, it would never work in a real application. One hung connection would make his whole server stuck.
If the author will not publish his source code I will: http://pastebin.com/CkJB6h2K
This is a 32 line Scala program. Yes Scala instead of Java but it is based on the exact same SocketServer that the author claims his program uses. It will sit there and listen for a connection, then do a simple imitation of HTTP. It even optionally supports HTTP Keep Alive.
Now to the test. I use the Apache AB tool: http://httpd.apache.org/docs/2.2/programs/ab.html
First without using -k (keep alive):
baldur@neaira:~/tmp$ ab -c 4 -t 10 -n 1000000 http://localhost:5555/
Time taken for tests: 10.000 seconds
Complete requests: 136991
Requests per second: 13698.99 [#/sec] (mean)
So about 13,000 requests per second processed on my old laptop. The author did 2000 requests in 2687 ms = 1344 requests per second or about 10 times slower than my program.
Lets try again with Keep Alive enabled:
baldur@neaira:~/tmp$ ab -c 4 -t 10 -n 1000000 -k http://localhost:5555/
Time taken for tests: 10.000 seconds
Complete requests: 692424
Requests per second: 69242.23 [#/sec] (mean)
So now we are doing 69.000 requests per second or 50 times faster than the authors program.
It might be that my old laptop is 10 or 50 times faster than the setup the author uses. But somehow I do really not think that is it. I think it is extremely likely that the author is a .NET programmer that has insufficient knowledge of Java to code this simple test correctly and that his program is simply wrong. More specifically I suspect that he did not know that you need to use a thread pool to process the connections, or if he did use one, that he used it wrong.
A stateless NAT should be lot easier on the machine than a firewall
Assuming that by NAT we mean the port address translation variety implemented by home gateways, there is no such thing as stateless NAT. For each inbound packet received from the ISP, the NAT device needs to know which of your internal machines is the intended recipient. It does so by looking up a relation in a table (external host IP, external host port, gateway port) -> (internal host IP, internal host port). This table is updated on outbound packets. If a relation is missing on inbound packets the gateway has no way of knowing where to send the packet and so has to drop it. It is from that property that a NAT device can act as a primitive stateful firewall.
Now some (=most home gateways) NAT devices cheat a little on that mapping (full cone NAT). Instead of recording the full relation as above, they record a reduced set of information. This makes them less secure, because a third party might be able to pass packets. Many NAT traversal techniques depends on the NAT device to "cheat" like this.
Notice that even the cheating devices are not stateless. Also note that a firewall could do the same tricks. It would become less secure in exact the same way as the NAT.
I am not sure why they bother cheating though. It does not really save any CPU power. The algorithm is only slightly less complex. They do save a little bit of memory as the tables will be smaller.
The real way to open a port is to use the UPnP Internet Gateway Device Protocol http://en.wikipedia.org/wiki/Internet_Gateway_Device_Protocol that allows software to request that a port be opened up. Most peer to peer software supports this.
I should also mention there is a RFC that requires customer routers to support IPv6 firewalling and to have it enabled by default: http://tools.ietf.org/html/rfc6204
NAT is harder than firewalling. Both requires the same connection tracking. But only NAT requires rewritting the packets. If your router is handling NAT it will do IPv6 firewalling as well.
Whats the worm traffic (ssh and other) on the IPv6 internet? The weird IPv6 people want us to just hop on IPv6 by tunneling under our old IPv4 firewall/routers. So how much parasitism and hacking is on the new network? And can we expect a wave of new attacks/exploits to happen to people who turn on IPv6 and blindly bypass the only protection they have?
Unlike IPv4, it is not practical to probe the IPv6 network blindly. You need to know the IP address of your target exactly. There is no guessing it.
A worm on IPv4 can send a packet to a random IPv4 address and have a high chance of that packet actually reaching someone. There are only about 4 billion IPv4 addresses. Even a single computer can send to every single IPv4 address in a span of only a few hours. If there are thousands of infected computers sending random packets, they got the IPv4 network covered in mere moments.
Fast forward to the IPv6 world. The IPv6 has an address space of 128 bits. This is the same size as strong encryption keys. Sending to a random address has zero chances of actually reaching anyone.
IPv6 addresses can be split into the first 64 bits called the prefix and the other half of 64 bits called the host identifier. Lets say you somehow learned the prefix of some user. But even if you only have to guess 64 bits of host identifier, the chances that you are going to hit his computer is so extremely low that we can call it zero.
What if you already know his full address? You wont for long. Most operative systems today have privacy extensions enabled. This is a system that makes your computer change the host identifier part of your address on a regularly basis (at least once per day).
People will still have routers and those will provide firewall services on IPv6. You would not get past that, but even if you did, you would not be able to simply guess an address. You can only send packets to people that recently sent packets to you first. Or which otherwise advertised the address through DNS or through a peer to peer network such as Bittorrent.
Bottom line: Classic worms and cold scanning is history on IPv6.
Isn't your bandwidth restricted by them though? I assume you're using he.net?
he.net are good. But if you are a Linux user it is easier to run this single command:
sudo apt-get install gogoc
Thats it. You got IPv6 through an automatic gogo tunnel.
But yes it actually makes your internet slower. Or at least it does for me. I am on a 40/40 fiber but the tunnel can not deliver anything near that.
Luckily, IPv6-only connections are becoming less useless every day.
Yep. I love browsing Slashdot at home with my IPv6 conn... oh wait.
Yes you can. Check this:
baldur@neaira:~$ telnet 2001:778:0:ffff:64::216.34.181.45 80
Trying 2001:778:0:ffff:64:0:d822:b52d...
Connected to 2001:778:0:ffff:64::216.34.181.45.
Escape character is '^]'.
GET / HTTP/1.0
HTTP/1.1 301 Moved Permanently
Server: Apache/2.2.3 (CentOS)
Location: http://slashdot.org/
Although due to that redirect you will have to put the IPv6 address for slashdot.org into your /etc/hosts file. Or you could use 2001:778::37 as your DNS server:
baldur@neaira:~$ host slashdot.org 2001:778::37
Using domain server:
Name: 2001:778::37
Address: 2001:778::37#53
Aliases:
slashdot.org has address 216.34.181.45
slashdot.org has IPv6 address 2001:778:0:ffff:64:0:d822:b52d
slashdot.org mail is handled by 10 mx.sourceforge.net.
This is called NAT64 and is admittedly not much better than carrier grade NAT. But it allows you to run pure IPv6 and still have access to the IPv4 internet.
Yes just google "java buffer overflow". There are tons of them. Here is an example: http://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?Name=Exploit%3AJava%2FCVE-2009-3869.M
The applet exploits a buffer overflow which existed in processing malformed images or audio files and affects Sun Java SE in JDK and JRE 5.0 before Update 22 and JDK and JRE 6 before Update 17. The applet exports Java class "vmain" with several member functions named "HB", "HexDecode", "mspray" and "paint". The member function "mspray" crafts an image in memory which is than passed to the "paint" function.
The "paint" function then calls "drawImage" from the standard AWT Java library causing a buffer overflow and potentially executing code from the memory allocated by the "mspray" function.
Yes the point is that you can make it "later" instead of "sooner". Example of this is the Google Native Client which exposes OS services through only an API consisting of a handful of allowed methods compared to the thousands of the Java platform. It is a lot easier to make 10 methods secure than 1000.
Native Client can run C code inside the Sandbox, so you can still take advantage of existing libraries.
Java code is sandboxed but many parts of the Java standard library is not written in Java. Every time SUN took the easy way out and used an external library instead of reimplementing in Java, they opened the platform to exploits of bugs in that library. Also it seems the SUN engineers did not really like to code in Java so they made a very large part of the platform in C - even when they could have made those parts in Java.
The standard library rt.jar file has more than 1000 methods that are implemented by native calls to C code or third party C libraries. It is simply too much to check that every single one of those crossed all the t's and dotted the i's. So we keep finding more bugs.
The sandbox itself is fairly secure so there is nothing wrong with the idea. It is just the implementation that went wrong.
You already know the location of the satellites without receiving anything at all from the satellites. The orbits are well known and downloaded into your GPS device. The satellites themselves have no way of knowing their own position, they only know the same data as was downloaded into your GPS. The only principal information from the satellite is the timing of the signal. The signal also tells you the time of the day with a precision of 1 second, but you hardly need an atomic clock to know that already.
Your basic misunderstanding of the system is that you believe you that you have 3 points. But the only thing you actually got is the timing of the relative delay of reception of three signals which gives you two values to work with. From these two values you have to calculate your position and no magical tricks can somehow infer three points from 2 values.
You seem to assume that you somehow know the distances to 3 satellites. But you don't. What you got is three time-signals. From that you can only infer two distances. Two is only enough for a 2D-fix.
That is what people have been trying to tell you. You need one satellite to be your time-fix.
The satellites will all send out a signal at exactly the same time. Because of the speed of light you will receive each signal slightly delayed and with a different delay for each satellite. When you receive the first signal you start your clock. You then measure time until you receive the second signal and then the third signal. It should be fairly obvious that you by this method only end up with TWO values from THREE satellites.
IF you did carry around your own atomic clock you could in theory be your own time fix. You would know _exactly_ when the satellites are going to broadcast their signal so you could start your timing clock before receiving any signal.
Atomic clocks are however big as a fridge, so nobody actually does this, not even the military.
That is for the insurance companies to figure out. If they can't, they will pay half each. Or they will sue each other. You wont care because your insurance wont go up since it wasn't your fault either way.
There is no problem here. It is not even any different from having a car today. What if your car has a fault that makes it accelerate unexpectedly and crash into someone (Toyota!)? The answer is your insurance will pay, then they will sue Toyota for the damages.
Load balancing/failover between different ISPs:
IPv6 - ISP cooperation and 1300EUR/year,
IPv4 - NAT router with software that supports this (for example pfsense) - can be completely free and does not need ISP cooperation or knowledge.
You got that one wrong. It is like this:
IPv6 - It just works, no extra software needed, no configuration or NAT router needed. No support or cooperation from either ISP needed.
With IPv6 you just order internet from multiple ISPs. You get a router from each. You connect said routers to your network. And you are done. If one router goes down or if the link or ISP goes down, all traffic will automatically move on to the other available options within a failover period of 30 seconds.
It is true that there will be no load balancing as such, only failover and not much in the way of configuring anything. In the larger picture, this will however make dual ISP an option for a lot of people that would never have figured out how to setup pfsense. My mom could do it.