prev. article next article

the future of the internet

1 Feb 2010


before thinking about ‘the future of the internet’ let’s have a look what the ‘internet’ actually is. the internet consists of two low level protocols, that is: tcp and udp and the most prominent protocol ip. and many other protocols are building on this, as http for instance. you are currently reading this blog page using http, that means you are also connected to the internet.

if you want to be a part of the internet you need a internet address - in short an ‘ip address’.** since most of use are using ipv4 that means often ppl share one ip which is bad since you can’t address some person sharing an ip with someone else directly. Sharing usually means NAT** - network address translation - and it also means that the internet does not work correctly. NAT is a failure and was never meant to be in the original design of the internet.

say you call your friend and he has no phone in his room - but one at his mother’s room. usually you can’t call between  [22,8] o’clock. the same thing is true for nat - you usually can’t reach the other person directly.

the only possible solution to this problem is ipv6. however we fail to integrate it. we currently fail at a lot of things (germany 2010):

So ‘what was the internet again’?

Actually the internet is much more than just what you can do with your browser using http. Before looking at http in detail let’s have a look at popular protocols which do NOT use http.

http problems

so after looking at the use case of ip let’s have a look at http and what** problems http has and how they are solved. the biggest issue using http is not the performance hit introduced by html/xml and bandwidth loss on the other hand. instead the biggest issue when using http is the fact that http is a ‘polling’ only protocol** so a client might download a webpage as: but then closes the connection. this works well when you only want to look at webpages and if you are only interested in client side events as mouseclicks & similar. but if you want to implement an interactive chat using http it gets more complicated since you would have to query the server every second for new messages from other users (even if there was no new message at all). the server CANNOT connect to your browser and tell you about ‘the new message’ right away as it is done in all the IM protocols.

so there are some new concepts as spdy:// from google [1] but there are other similar ideas as well. all lead to a next generation http protocol with callback capabilities. opera for instance features ‘a socket in the browser’ which is a interesting concept. both concepts transform the ‘user’ from a pure consumer into a ‘consumer/producer’.

in the first days most internet providers had ‘terms’ in their ‘terms and agreements’ which forced you to offer no webservices with your private internet connection. the situation since the internet was introduced has changed and providers now sell devices as the fritz-box with DDNS clients for services as preinstalled. this change needs to be extended further as the classic pattern of ‘private’ and ‘commercial’ usage merge more every day. it gets hard to distinguish between the service levels needed for either of the two scenarios. we need to extend:

So after some history, what makes opera with websockets revolutionary? It’s the ‘ease of use’ to put content online. You don’t need a provider to host your stuff, just host it yourself! But there are pitfals as upload bandwidth is small even with VDSL, i don’t know why… my scale of guesses range from:

there are many points for both sides and i don’t have much background to make a good guess.

Some final thoughts: