Internettet på vej mod forstoppelse

De skal da bare ha udbygget kapasiteten.

Og google betaler da også for datatrafikken.
Det er da kun private og små firmaer der ikke gør det.
Ligesom ISP'erne imellem.
Jeg ser ikke noget problem i at de betaler for de de sender. Som de allerede gør....

Og så burde vi lave nogle flere peer to peer løsninger i stedet for dyre server - client løsninger...

»Det er lykkedes for visse fortalere for netneutralitet som Google og Yahoo at drukne den diskussion, fordi de har baseret deres forretning på gratis leverance til forbrugerne, og at det er billigt for brugerne at have en forbindelse. Men hvorfor skal Google og Yahoo ikke betale noget som helst for at få leveret deres produkt hos forbrugeren,« spørger Jens Ottosen-Støtt.

Ikke det argument igen! Jeg ser det som manipulation. Google betaler sin internetregning som alle andre. Telebranchen så sikkert gerne, at de fik betaling to gange, men hvis de ikke allerede fik hvad der er deres, hvorfor er de så i branchen til at starte med?

Jeg vil tro, at man i teleselvskaberne er frustrerende over, at det er internetfirmaerne der skummer fløden, mens de selv har den kedelige opgave med at flytte bits fra a til b. Er det en violin jeg kan høre?

Jeg ser klart disse udtalelser som værende fra lobbyister, for at teleudbyderne kan prioritere trafikken i internettet til egen fordel.

Jeg kan ikke huske et eneste år, medens jeg har været på internettet, hvor der ikke er kommet dommedags udtalelser.

Ja, man kunne fx forestille sig en model hvor brugerne får lov til at sende store mængder trafik ved høj hastighed indenfor deres egen central. Så skal vi blot have en standardiseret metode til at hente en liste over high-speed IP adresser.

Hvis man vælger at leve af at levere en vare i en eller anden branche, så er det nødvendigt at kende til livsvilkårene for fortsat overlevelse i den branche.
Det gennemsnitlige forbrug af båndbredde hos backbone leverandørerne, stiger med ca. 70% om året (tal baseret på subjektive betragtninger siden 300 baud var hot). I år 2003 fik jeg også uofficielt bekræftet at det var den prognose som man projekterede efter for TDC's backbone.

Så få det dog lært!!! Vi gider ikke længere at høre marketing og budget chefernes patetiske beklagelser om, at de ikke kan leve for evigt af det samme flæsk - uden at de også skal bruge penge til udvikling, research og vedligeholdelse.

Så få det dog lært! Råvarer koster, og når en råvare er brugt op/overforbrugt, så har man bare at have en ordentlig model for i tide at kunne forudse det, så man har sikret at der er nye og tidssvarende varer på lager!
Ellers så vil konkurrenten jo bare overtage markedet. Så tag jer dog sammen i klynkende nokkefår.

At være Internet båndbreddeleverandør har i en årrække tydeligvis været en alt for lukrativ forretning, ellers så var der jo ikke så mange forskellige virksomheder som havde kastet milliarder af kroner efter at lave parallelle løsninger.
Hvis man ønsker at få en bid af naboens kage (Google og Yahoo bliver nævnt) fordi man syntes, at man ikke får nok ved at sælge tørt rugbrød, og naboen tilsyneladende har meget større omsætning/avance ved at sælge smørrebrød og konditor kager, så må man jo skifte varesortiment - eller købe sig ind i en del af naboens forretning. Det er markeds vilkårene! Så få det dog lært!!!

Vi ser jo også at Google investerer i både datacentre og global infrastruktur, så kabel folkene ikke har lige så let ved at presse penge ud af en indholdsleverandører, bare fordi de ejer nogle "gamle landeveje" af kabelforbindelser.

Vi køber simpelthen ikke jeres flæberi. Så få det dog lært!!

Det her handler om at optimere profit.

Hvordan skal transparency virke med hensyn til hvilke protokoller der skal koere high speed eller prioriteres i forhold til andre?

Forestil jer at Skype bliver opfundet efter at det her bliver implementeret... Nej vel, foerst skal du vaere en golbal spiller, der har raad til at faa deres protokol godkendt til high speed og derefter kan du gaa igang med at udvikle det naeste innovative projekt.
Beslutningen ER taget, det handler om at telcos skal have initiativet tilbage, om at media firmaer skal kunne bestemme over leverings kanalerne ligesom dengang vi kun havde CD'ere

Maaske er en ny tilgang til netværk og de benyttede protokoller...en overvejelse værd !!?

Netværks/eksperten Van Jacobson giver sit bud"

"A New Way to look at Networking" af Van Jacobson
"Google Tech Talks" 30 august 2006
http://video.google.com/videoplay?docid=-6972678839686672840

Van Jacobson har arbejdet med computer-netværk siden 1969 - og må regnes som en af verdens mest vidende på området.
I dette foredrag beskriver han i den ene halvdel af foredraget, hvordan vores nuværende håndtering af netværk i udstrakt grad bygger på en forældet og problematisk netværksteknologi. Og i anden halvdel, giver han sit bud på et mere datacentreret netværk.

Her er Googles omtale af Van Jacobson, og foredraget:

"Van Jacobson is a Research Fellow at PARC. Prior to that he was Chief Scientist and co-founder of Packet Design. Prior to that he was Chief Scientist at Cisco. Prior to that he was head of the Network Research group at Lawrence Berkeley National Laboratory. He's been studying networking since 1969. He still hopes that someday something will start to make sense. ABSTRACT Today's research community congratulates itself for the success of the internet and passionately argues whether circuits or datagrams are the One True Way. Meanwhile the list of unsolved problems grows. Security, mobility, ubiquitous computing, wireless, autonomous sensors, content distribution, digital divide, third world infrastructure, etc., are all poorly served by what's available from either the research community or the marketplace. I'll use various strained analogies and contrived examples to argue that network research is moribund because the only thing it knows how to do is fill in the details of a conversation between two applications. Today as in the 60s problems go unsolved due to our tunnel vision and not because of their intrinsic difficulty. And now, like then, simply changing our point of view may make many hard things easy.«

Her en omtale af konceptet bag "Content-Centric Networking":

"Content-Centric Networking:
Get Your Data When You Want It, Where You Want It

A cell phone is a comforting device. Even if you turn the ringer off, it vibrates reassuringly – letting us know that we can connect to anyone, anytime, anywhere. With our lives encased in its palms, the cell phone anchors us in a constantly shifting ocean of information and locations.

But the reality is that cell phones – along with other mobile and wireless devices such as laptops and PDAs – don’t really allow us to access information from any place or at any time. Marginalized to the fringes of the network, mobile and wireless applications simply aren’t supported by current networking approaches. In fact, most networking approaches today are outdated.

The time is ripe for change

Networks today were designed for the technologies of the 1970s, when people accessed limited information, on a static network, through a single computer system. So current networking approaches focus on moving packets of data – which are attached to a fixed machine location and unique IP address – from source to destination.

But in today’s networking environment, people access unprecedented amounts of digital information, through dynamic networks, and with multiple, often mobile devices. So the time is ripe for a fundamentally new approach to networking.

What’s needed: a way for networks to self-organize and optimize performance – using available resources and making decisions based on the information inside it – instead of blindly responding to abstract, IP-based data requests.

Enter content-centric networking

With content-centric networking, the network itself doesn’t matter…but people's needs do. Content-centric networking focuses on data content (instead of data location), so people can easily send and receive named digital content from multiple locations, mobile devices, and diverse networks – without having to manually configure a network connection or identify what server the data lives on. Anything that moves provides connectivity, so you don't have to be formally connected to the Internet to access networked information. Named content migrates wherever it’s needed, using any device and any means available.

Content-centric networking allows communication to happen anywhere, anytime, and with any device — using any available means. Most importantly, it makes network plumbing "invisible" to people, so they don't have to get their hands dirty with plumbing network connections.

Besides drastically simplifying and improving people' lives, content-centric networks also dramatically improve efficiency and security – because the network now knows what content is moving inside it. By fundamentally shifting current networking architectures, content-centric networks can self-organize on demand and scale easily while still meeting people's information needs.

Content-centric networks can better address the networking needs of today – especially mobile, wireless, sensor, and advanced multimedia applications – and enable a whole host of new collaborative tools tomorrow. No longer providing just a false sense of comfort, the cell phone – or any other device for that matter – will truly allow us to connect to anyone, anytime, and anywhere.

The people behind the evolution

With its rich legacy of network innovation, diverse application expertise, and trademark human-centered approach, PARC is in a unique position to innovate content-centric networking. Led by award-winning industry leader Van Jacobson – who is renowned for solving the global problem of network congestion and helping the Internet scale in size and speed – PARC’s content-centric networking research program aims to restructure the way networks manage resources and distribute information. It's the next evolution in networking, and we're innovating it now."

Det er ikke mere end en måned siden at jeg læste det stik modsatte..

At Internettrafikken godt nok var steget de sidste mange år som spået, men at kapaciteten også var blevet forbedre, faktisk var kapaciteten blevet forholdsvis større end behovet.

Hvis jeg kommer efter hvor jeg læste det, så kommer der selvfølgelig et link.

Udklip/Citater fra Parc.com......Visioner og teknologier:

Content-centric networking

PARC’s rich legacy of network innovation includes inventing the Ethernet and PUP; pioneering client-server and peer-to-peer concepts; advancing IP multicast and Mbone; and co-designing Internet Protocol version 6 (IPv6).

Content-centric Networking — A new paradigm for networking focused on content – named “chunks" of data – as the new glue of the Internet, rather than connectivity to hosts or networks

THE RESULTS: Enabling the Human Network

Content-centric networking will drastically simplify people’s lives, and support a host of new and emerging applications . The network can communicate on a person’s behalf from inside the network, by focusing on what he or she actually wants instead of meaningless abstractions. A person can also express intent to the network – for example, a parent working from home can instruct his home network to prioritize work-related e-mail over his teenager’s social web traffic.

As the network self-organizes, content-centric networking eliminates the need for time-consuming and cumbersome plumbing. Content will move where it needs to, in the most efficient manner possible. Let’s say a person riding on a bus wants to retrieve a New York Times article on her laptop; the network can retrieve the content through her neighbor’s cell phone instead of manually connecting to a more remote newspaper server location.

Content-centric networking facilitates mobility, autonomous sensing, and wireless access , sometimes by using simple and quick local protocols. Under current networking architectures, you’re either entirely “in” or “out” of the network. No connection? No network. Content-centric networking, however, enables your information and the network to always be available – even in locations with limited network resources (including developing countries and demand-response situations).

Content-centric networking enables communication to happen with anything, anytime, anywhere.

Content-centric networking could eliminate security problems such as spam, phishing, pharming, and so on, because it secures the content instead of the channel.

Under current network-security approaches, even the most secure mail server will send spam because the network doesn’t know what content it’s moving. Using content-centric networking, integrity and trust are properties of the data – not of the corruptible way in which it arrives – so content can be validated upon arrival. Content-centric networking addresses security at an architectural level.

Content-centric networking dramatically improves network performance on a broad scale by:

* improving efficiency by at least three orders of magnitude;  
* reducing congestion and latency because the same or irrelevant information isn’t repeatedly sent through the same pipelines;  
* increasing reliability because information is delivered using any available medium; and  
* reducing set-up time, manual configuration, and operating costs.

PARC’s VISION: Shoot the Messenger, Not the Message

Imagine that you can receive or send any package, without having to go to a post office or address the envelope. You simply hand it to anyone (it doesn’t even have to be a certified delivery person), perhaps a handsome stranger nearby. The package would pass to your intended recipient by any means available – plane, train, paper airplane, pigeon – as quickly and efficiently as possible. When your recipient receives the package – on whatever location, device, or network she’s using at that moment – the authenticity of the package’s contents could be verified by an embedded code reader or similar technique. This scenario may sound like something you’d find only in J.K. Rowling’s Harry Potter world of owls and magic, but it’s analogous to what the network does under content-centric networking.

THE SOLUTION: From Abstract to Meaningful

What would happen if the TV station’s network could distribute information more efficiently by disseminating content – instead of blindly conducting abstract, location-based conversations between source and destination nodes?

THE SHIFTING LANDSCAPE: Moving from Phone Calls to Cocktails

PARC attributes many of these problems to limitations in underlying networking architectures, which are based on obsolete assumptions. Packet-based protocols for delivering data across networks were developed in the 1970s, when people had no choice but to:

* connect to homogenous, static networks at the same time;  
* use a single computer mainframe system that often was shared among multiple users; and  
* access limited amounts of information.

As a result, the Internet protocols (IP) that are still in use today send data in chunks (as identified by a globally known, topologically stable, unique IP address) from source to destination – regardless of the information contained within them.

It’s ironic that the success of these outdated network protocols has created a new information world, and posed a new problem: everything seems to be – or wants to be – connected to everything else. In today’s networking environment, people can:

* connect to diverse, dynamic networks at various times;  
* use multiple, often mobile devices; and  
* access ever-growing amounts of digital information.

Considering the proliferation of wireless and peer-to-peer networks, multicast, broadcast, voice over IP (VoIP), ubiquitous applications, and the advent of context-aware computing, the time is ripe for a fundamentally new approach to networking.

The network of today is different from yesterday’s: Internet communication has moved from point-to-point conversations between hosts, to point-to-multiparty or multiparty-to-multiparty information dissemination. It’s the difference between setting up a phone call between two friends, and hosting a cocktail party.

How does this difference relate to underlying network architecture? You can’t use a telephone to host a cocktail party – where people engage in multiple conversations, move around, eavesdrop on conversations, and ask nearby guests for information. Under current networking assumptions, information processing and content-related work happen only at the ends of the network – as in a phone call between two individuals. Yet sending information based solely on its end-to-end location doesn’t allow the network to maximize available resources and optimize performance based on the nuanced interactions and information inside it.

Here’s an example: during a recent Olympic games broadcast, a major TV station server was overwhelmed by simultaneous requests for a video URL that captured a critical game moment. Since the router was unaware of the content (i.e., it didn’t know that the same information was being requested by many different destination nodes), it choked by responding individually to each of 5,000+ requests. Had the router known about the content it was sending, it could have efficiently handled the requests (e.g., via broadcast, flooding, etc.).

Usorterede tekster om et emne det har vi Google til at levere. Hvis der er en pointe i alt det vrøvl der så prøv at gengive den i kort form i stedet for bare at kopiere tilfældige tekster ind.

Bare en lille rettelse: Så vidt jeg husker er 1 petabyte 1.000.000 gigabyte så 20.000 petabyte er 20.000.000.000 gigabyte!

Der er bestemt ikke tale om tilfældige citater...men jeg forlanger ikke at du konsumerer det hele.
Mit ærinde er information - ikke tilfældig citation.

Men når en en fædrene til TCP/IP..Van Jacobson arbejder seriøst med alternativer til sine egne opfindelser, så synes jeg, at der er grund til alert.

Og debatten i denne tråd....handler jo i udstrakt grad om netop flaskehalsproblemer med hele Internettets samlende led IP.....Og dette store protokolproblem..vil Van Jacobson og andre gerne afhjælpe....

Det er jo netop "konservativ" fastholdelse af en forældet protokolhåndtering...der er en af hovedårsagerne til overbelastning på Internettet.

Finn Nørbygaard definerede engang det jydske ord "træls".
Forestil dig at du kører ude på motorvejen og bliver overhalet af en flok Hells Angels. Du dytter efter en af dem og pludselig sætter hornet sig fast. Det er godt nok træls!

Samme følelse må man få når man sidder og skriver et indlæg på Version2, og punktumtasten pludselig går amok.

Uanset relevansen så hører citater af den længde ikke til i et forum, du kan give et link således at folk som finder dit indlæg interessant kan læse mere om emnet. Som hovedregel vil jeg sige maks ~10 linjer citat i et indlæg.

Dertil bryder du totalt med en god journalistisk regel, det vigtigste først. Hvis ikke de første 10 linjer fænger, så gør resten heller ikke, for de bliver ikke læst.

Der findes faktisk folk der samler på punktummer !!

I mit tilfælde - så er tankestreger og punktummer, noget jeg
anvender meget i diverse tekster....

Og du ville sikkert ikke have undret dig over mange punktummer - hvis du læste matematiske tekster, eksempelvis om lineær algebra !?

Andre kan ikke lide mange citater...da de mener, at det kan de da bare "Goorrrgle".

Det er sgu vanskeligt at tilfredsstille alle - specielt de der har en "konform" indstilling til anvendelse af sprog, tegn og grammatik.

@ Jacob du skriver"

"Dertil bryder du totalt med en god journalistisk regel, det vigtigste først. Hvis ikke de første 10 linjer fænger, så gør resten heller ikke, for de bliver ikke læst."

Her hvordan mine to lange indlæg starter - og, hvis du ikke kan tolke, hvad det handler om...er det ikke min fejl !!

"A New Way to look at Networking" af Van Jacobson

Maaske er en ny tilgang til netværk og de benyttede protokoller...en overvejelse værd !!?

Netværks/eksperten Van Jacobson giver sit bud"

"A New Way to look at Networking" af Van Jacobson
"Google Tech Talks" 30 august 2006
http://video.google.com/videoplay?d...

Van Jacobson har arbejdet med computer-netværk siden 1969 - og må regnes som en af verdens mest vidende på området.
I dette foredrag beskriver han i den ene halvdel af foredraget, hvordan vores nuværende håndtering af netværk i udstrakt grad bygger på en forældet og problematisk netværksteknologi. Og i anden halvdel, giver han sit bud på et mere datacentreret netværk.

"A New Way to look at Networking"...fortsat....Selvorganiserende "Content-Centric networking"

Udklip/Citater fra Parc.com......Visioner og teknologier:

Content-centric networking

PARC’s rich legacy of network innovation includes inventing the Ethernet and PUP; pioneering client-server and peer-to-peer concepts; advancing IP multicast and Mbone; and co-designing Internet Protocol version 6 (IPv6).

Content-centric Networking — A new paradigm for networking focused on content – named “chunks" of data – as the new glue of the Internet, rather than connectivity to hosts or networks

Jeg fanger nogle spredte elementer. Noget nyt, noget med noget netværk, en gammel nisse som har holdt et foredrag, så begynder et stykke på eneglsk hvor der står noget som jeg lige har læst på dansk. Der går klappen ned, det kan jeg simpelthen ikke holde ud at læse. Jeg fornemmer at der angiveligt skulle være noget revolutionerende ved det her.

Mavefornemmelsen siger at det er noget ubrugeligt flip, men jeg kan ikke helt udelukke at den dårlige præsentation har givet mig en grad af bias.

Den dybeste mening jeg har hevet ud af teksten er at det handler om multicasting. Det har været et varmt emne i lang tid, men det meste netindhold er meget svært at multicaste. Ved ideel multicasting sender man data til alle modtagere samtidig, men folk vil have deres indhold når de beder om det, altså bliver man nødt til at caste relativt ofte, hvilket resulterer i at man servicerer relativt få brugere per cast. Men hvis man rent faktisk skal spare noget ved multicasting så skal der ikke bare være flere brugere per cast, der skal være flere brugere som kan udnytte de samme backboneforbindelser, og det er det lidt småt med hvis man caster til 100 brugere som er spredt over hele jorden. Dertil kommer så at samtlige involverede ISPer skal modtage dataen ved samme hastighed, hvilket er lidt problematisk når de forskellige kunder har betalt for vidt forskellige forbindelser.

Teoretisk kunne man cache data i diverse knudepunkter, men i de store knudepunkter er det ikke teknisk muligt, det er ikke så meget selve datamængden som det at skrive og læse hurtigt nok til at det kan bruges til noget. I de små knudepunkter skal der ekstra hardware til, men trafikbesparelsen bliver nok alligevel til at overskue, for mængden af data som har været igennem før er lavere.

Det absolut bedste som går i retning af multicast er peer to peer netværk, de kan potentielt prioritere tætliggende peers højere og på den måde spare backbone, men det er stadigvæk få data som er så efterspurgte at det virkelig kan gøre en forskel.

@ Jacob

IP Multicasting er kun en lille del af hele konceptet "Content-Centric Networking"/"Data-Centric Networking".

Broadcasting er en langt mere essentiel del af konceptet.

Van Jacobson sammenligner sine visioner om Internettet, med
Broadcasting af radiobølger - hvor der afsendes uden forespørgsel, mens det er mulige modtagere der har "problemet" med at tune ind paa den rette kanal.

-Van Jacobson
"In the third era of digital content labeling, content packets will be broadcast from a starting point in the same way that radio waves are broadcast from a radio station. People searching for that content will be able to locate it in the same way that we can search for a radio station. The advantage of this new approach is that there would be no duplication of content and that it is built on a broadcast model rather than on a model of two people communicating."

Van Jacobson har forlængst erkendt, at der skal arbejdes
på mange fronter - både på det fysiske og logiske niveau
- hvis hans visioner skal implementeres.

Han har f.eks. været stærkt involveret i en omfattende optimering af netværks-stacken i Linux.

Og Jacob - man skal ikke underkende de folk, som vi står på
skuldrene af...Mange af de "gamle nisser" har et overblik og
en erfaring - som mange yngre IT-professionelle, jo af naturlige årsager ikke kan have.

IGEN er der nøjagtig den samme historie på ing.dk og version2.dk:

http://ing.dk/artikel/92069
http://www.version2.dk/artikel/8721

Sidste gang jeg gjorde opmærksom på det fik jeg at vide at der var sket en fejl. Er det så også en fejl denne gang?

Hvis i så i det allermindste sørgede for at kommentarer til den ene historie dukkede op begge steder, men nej.

(Denne kommentar er derfor postet begge steder så folk har en chance for at se kommentarer i begge tråde...)

Peter

Begrebet broadcasting giver normalt ikke mening i forbindelse med internettet, men hvis vi skal overveje konceptet så er den tætteste eksisterende teknologi vel en hub. Vi kan sige at hubben broadcaster til alle tilsluttede klienter. Singlecast modstykket er så en swich.

Karakteristisk er det at hubben virker fint til små netværk hvor trafikken er begrænset, men hubben kan slet ikke skalere til store netværk, det klarer en swich meget bedre.

At forsøge at broadcaste på internettet er vel mere eller mindre analogt til at opbygge hele internettet af hubs.

Du kunne måske finde et citat som forklarer lidt mere om de tekniske aspekter af hans ide? Jeg savner nogle konkrete informations flow modeller.

Enig... Det eneste der sker hvis vi beder indholdsleverandørene betale en del af regningen er at de begynder at bruge mindre båndbredde, hvilket unægteligt betyder mindre indhold. Hvilket rammer innovationen...

Samtidig vil jeg dog også sige at man skal passe på med at indføre net neutrality... For hvis vi indfører net neutrality, da dette kan være med til at ødelægge innovation på backbone niveau. Hvad hvis nu en ISP ønskede at cache f.eks. google.com og bare svarer alle standart anmodninger om denne side med side fra cachen? (ved ikke om det praktisk talt kan lade sig gøre lige præcist som beskrevet i mit eksempel...) Men kunne man forestille sig at det var muligt, givet en lovgivning der siger at trafikken skal følge nogle bestemte internet standarter?

@ Jacob

Jeg kan give dig nogle links, og et par citater fra et site der beskriver en del af Van Jacobsons ideer - håber det giver dig lidt flere hints !?

"Combined Broadcast and Content-Based (CBCB) routing scheme.
This scheme consists of a suite of protocols that implement a content-based network."

http://www.inf.unisi.ch/carzaniga/cbn/routing/index.html

A. Carzaniga, M.J. Rutherford, and A.L. Wolf (2004)
"A Routing Scheme for Content-Based Networking"
http://www.inf.unisi.ch/carzaniga/papers/crw_infocom04.pdf

A. Carzaniga and A.L. Wolf (2003)
"Forwarding in a Content-Based Network"
http://www.inf.unisi.ch/carzaniga/papers/cw_sigcomm03.pdf

Og endelig et "langt" citat...fra samme site, som ovenstående er hentet fra:

"In a content-based network, receivers declare their interests to the network by means of predicates, while senders simply inject messages into the network at the periphery. The network is responsible for delivering to each receiver any and all messages matching the predicate declared by that receiver. As in traditional address-based networks, the delivery function is performed incrementally by passing messages between intermediate nodes in the network. The delivery function consists of two interrelated subfunctions: routing and forwarding. Routing amounts to establishing flow paths through the network by compiling and positioning local forwarding tables at each node. A forwarding table contains the information necessary for a node to decide to which neighbor node or nodes a given message should be sent; the processing of a message at a node is the forwarding subfunction. Taken together, the forwarding performed at the nodes causes messages to be routed through the network."

@ Jakob

Et citat mere, som jeg ikke fik med i foregående indlæg:

"CBCB is a routing scheme that implements the content-based network service over a generic point-to-point network. CBCB is based on two fundamental ideas. First, CBCB uses a broadcast layer to abstract the topology of the underlying network (overlay or physical). The broadcast layer is used in various phases of the routing protocols, as well as by the corresponding forwarding protocol. Second, CBCB uses a push/pull protocol to propagate routing information."

@ jacob

Og her et noget mere aktuelt link fra Antonio Carzaniga - April 2008

"Content-Based Communication: The Network Underneath Event Processing"

http://logic.pdmi.ras.ru/~infclub/files/networking03_handout.pdf
(46 sider slides)

Okay, jeg tror efterhånden at jeg har fået nogenlunde fat i konceptet, der er tale om en form for muliticasting, til gengæld skal en forespørgsel fra en helt almindelig internetbruger broadcastes til samtlige noder i et backbone net, enhver multicastet pakke skal sendes til mindst en af disse noder.

Problemer:
Noderne i backbone nettet skal gemme et stort antal forespørgsler, og matche dem med pakker. Det er ikke blot trafik overhead, der skal også oprettes store hurtige databaser over det hele for at holde styr på forespørgslerne.
Administrationen af forespørgsler er ekstremt vanskelig, i et loopfyldt netværk skal det sikres at ingen node får den samme pakke sendt flere gange. Det vel at mærke i et netværk hvor størstedelen af forespørgslerne ikke er beregnet til at blive brugt, da de ikke ligger på vejen til modtageren. Imidlertid kan en node med en af disse forespørgsler godt modtage pakken, blot på vej til en anden modtager.
Dertil kommer samtlige problemer som traditionel multicasting lider under, hvilket jeg allerede har skrevet om.

Og så har jeg slet ikke talt om problemerne med at sikre data integritet, alt skal signeres, og nogen skal bruge kræfter på at verificere signaturen før det udsendes for at sikre mod DoS angreb.

@ Jacob

De problemer du adresserer er bestemt væsentlige!
Og jeg vil komme tilbage senere, med nogle flere links omhandlende de problemer du har skitseret.

Nu er jeg ikke netværksspecialist, så jeg skal ikke rode mig ud i de mere tekniske detaljer omkring dette.

Til gengæld vil jeg henlede din opmærksomhed på XML-teknologierne, som jo i udstrakt grad anvendes idag - og sandsynligvis bliver hele grundlaget for håndtering og transport af data på Internettet (og i netværk generelt).

XML blev jo primært udviklet for at optimere datatransport på Internettet.
At udviklingen af XML også har/havde andre formål, er en helt anden sag.

Et "barn" af XML, er jo det vidt udbredte RSS - og med RSS har du netop et eksempel på Asynkron Broadcasting.

Og til slut lidt fremtidsvisioner/-illusioner eller "sidespring":

Web 3.0 / The Semantic Web, med XML som fundament...Web 4.0 / WebOS, med (Linux?) og (Firefox?) som fundament.......Og endelig det helt "flippede" Web x.0 / Spime / The Internet of Things, som vi allerede har flere eksempler på, men som først spås at være fuldt udviklet og implementeret omkring 2050!?

Du har helt klart ligesom mange andre fået et helt forkert indtryk af XML.

Et eller andet grødhoved syntes at vi manglede en "standard for alt", det blev XML.

XML er et subset af standarden fil. Den dikterer i grove træk at man udover sine data også skal gemme en masse overhead i filen. Man kan bruge XML til at gemme en hvilken som helst type data, ligesom fil formatet, det fylder bare en del mere. Dertil stiller XML formatet specifikt det krav at data kan være skrevet i en hviken som helst rækkefølge, hvilket gør at man ikke kan definere sit subformat på en smart måde således at programmer kan læse XMLen i den rækkefølge der er brug for de forskellige data.

XML bliver ofte kaldt en teknologi. Jeg ved ikke hvorfor, det åbner ingen muligheder, der ingen opfindelser bag. XML kan ingenting, det er en tom skal af ligegyldig overstandardisering.

RSS er smart nok, men det har ikke noget med valget af XML at gøre. XML gør blot at RSS bruger unødig båndbredde. RSS benytter sig i øvrigt af singlecasting via ganske almindelig TCP/IP. At det ser lidt multicasting agtigt ud er ren illusion.

I øvrigt har jeg en ide til en protokol som kan spare på backbone nettet. Basalt set skal ISPer blot have lov til at cache de data som sendes via protokollen, og levere svar fra cachen i stedet for fra indholdsudbyderen, dertil skal de have lov til selv at bestemme i hvilken rækkefølge de leverer bidderne af den data. Det betyder at ISPen ikke behøver at cache hele datamængden, men i stedet kan indhente den løbende og bare lade nytilkomne klienter hoppe på midtvejs, de kan så få starten i næste loop.

Hvis en ISP ikke har implementeret protokollen kan klienter fra den ISP godt hente data alligevel, de bliver bare singlecastet uden nogen form for besparelse.

Jeg tvivler lidt på at den kan vinde udbredelse, men den er, i modsætning til Content Centric Networking, realistisk at implementere. Succesen vil nok primært afhænge af om der er ISPer som vil tilslutte sig ideen. Indholdsudbydere af specielt video og andre tunge ting burde kunne se en klar fordel.

@ Jacob

XML kan ikke noget i sig selv.

På samme sæt som heller ikke Assembler, C, Perl ....etc.,
kan noget som helst - uden brug af det helt grundlæggende hardware, og diverse software: loader, linker, compiler, interpreter ....etc.

Endvidere burde man have en del mere IT-historie på DTU !

GML - SGML - XML - o.s.v.

I 1960'erne, stod IBM med problemer omkring håndtering og præsentation af ustrukturerede dokumenter - og her taler vi om flere millioner sider dokumenter.

Et billede på problematikken kunne være flg.:

Hvordan får man en flyvemaskine ind i en database !?
Og hvordan får almindelige mennesker adgang til databasen og dens dokumenter - på en præsentabel, letforståelig og ikke mindst let manipulerbar måde.

Et andet eksempel for store samlinger af dokumenter, er en stats lovsamling.

IBM valgte juristen Charles F. Goldfarb som leder af en arbejsgruppe, som skulle komme med et bud på løsninger af ovennævnte problematik.

I 1969 var arbejdsgruppen klar med en løsning, som fik
navnet General Markup Language.

Med Charles F. Goldfarb som motor, fortsatte videreudviklingen af GML - til anvendelse på flere og flere områder.

I 1986 fik vi så StandardGML - som er en industristandard for udvikling af Markup Languages til håndtering af elektroniske dokumenter.

Der findes en del "gamle nisser" eller "grødhoveder" som lærte sig at beherske SGML.

Igen blev Charles F. Goldfarb motor for udviklingen af SGML i en "lightudgave".
Og i 1996 kom resultatet - XML blev realiseret.

Siden 1996 har vi så set de utallige forgreninger som XML har resulteret i - eksempelvis RSS, som vi har talt om.

Og sandelig er det datateknologier...både rent abstrakt - og sandelig også fysisk implementeret/repræsenteret.

PS !

Jeg husker, hvordan man satsede på PDF i den grafiske branche, som et universelt dokumenthåndteringsformat.
Men sammenlignet med XML til dokumenthåndtering - så er PDF ikke en
god løsning, da det ikke er fremtidssikret.
PDF mangler det semantiske element, som er så vigtigt for at kunne bevare og finde data i fremtiden.

XML kan opbevare data, præcis ligesom den fil det er bygget ovenpå.

Diverse programmeringssprog bliver til mere end blot tekstfiler pga. en compiler. Jeg vil nu heller ikke kalde et programmeringssprog for en teknologi. Selve konceptet med et abstarkt sprog og en compiler kan vi kalde teknologi, og jeg vil også gå med til at kalde nogle udvidelser af konceptet for teknologi, men selve sprogene bygger blot på teknologi, de er ikke teknologi i sig selv.

XML bygger også på teknologi, men ikke noget ud over den teknologi som filer bygger på.

GML er et rent dokumentformat, nede på jorden, forholdsvis kompakt, og let for mennesker at læse og redigere.

At kalde SGML for en videreudvikling af GML er noget af en tilsnigelse, det er et "format format", det har en helt anden anvendelse end GML, det tager nogle elementer fra GML, men bruger dem i en helt anden kontekst.

Brugen af SGML er meget mere kompliceret, ideen om at materialet er let tilgængeligt for fremtiden pga. standarden er også blevet en del mere udvandet, folk definerer selv deres subset, og det er det som afgører hvor fremtidssikret materialet bliver.

HTML er forholdsvis tro mod GML ideen, men det lader sig nok mest gøre fordi det også er et sprog til at representere tekst.

Jeg vil hellere kalde TeX for en efterfølger til GML, for rent funktionsmæssigt og ideologisk har det mere til fælles med GML end SGML har.

XML er så et subset af SGML som har droppet nogle unødvendige features (som fx muligheden for selv at vælge tags). Det er ikke et dokumentformat, og det bliver heller ikke brugt sådan, selv ikke XML dokumentformaterne ODF og OOXML kan siges at udnytte XML som dokumentformat, det er sølet ind i alverdens formateringer, spredt ud på flere forskellige filer og pakket sammen i en zip fil.

Jeg kan ikke forstå hvorledes du finder på at sammenligne XML og PDF, de to formater har intet overlap i funktionalitet. Nogle XML substandarder kan sammenlignes med PDF, men det er noget helt andet.

@ Jacob

Du burde fortælle hovedmanden bag GML, SGML og XML..Charles F. Goldfarb, at han slet ikke ved, hvad det er han har lavet de sidste 40 år.

Jeg forholder mig til standarderne og den måde de bliver brugt på, uanset om Goldfarb er Julemanden selv så er han ikke rigtigt relevant for emnet. Hvis ikke du vil gå efter bolden så kan vi lige så godt lade være med at diskutere, jeg tror alligevel at læserskaren til de seneste indlæg kan tælles på to fingre.