Nieuw bedrijf adresseert bandbreedteproblemen RSS

Nadat we eerder al schreven over de bandbreedteproblemen die ontstonden door het gebruik van RSS-feeds, laat eWeek nu weten dat een nieuw bedrijf hier handig gebruik van maakt om zijn diensten aan de man te brengen. Bloglines kondigde dinsdag aan dat het een webservice-programma opgericht heeft waarmee gebruikers gratis verbinding kunnen maken met zijn servers om zo in RSS feeds te zoeken en ze te lezen. Hiervoor zijn drie verschillende programma's beschikbaar, te weten FeedDemon, NetNewsWire en Blogbot. Bloglines werd in juni vorig jaar opgericht als een onderdeel van Trustic, om RSS- en Atom-feeds te verzamelen en om het uur te controleren of er updates zijn.

Volgens CEO Mark Fletcher is het systeem best te beschrijven als een RSS-cache, zodat het bandbreedteprobleem opgelost wordt, wat het aanbieden van RSS-feeds moet stimuleren. Bloglines biedt echter zelf geen software aan om de feeds te lezen, zodat gebruikers steeds op de website moeten inloggen om hun favoriete feeds te lezen. De drie eerdergenoemde programma's zullen nu verbinding kunnen maken met de Bloglines-dienst, zodat gebruikers zelfs van op hun desktop op de hoogte kunnen blijven van het nieuws waarin ze geïnteresseerd zijn.

Reacties (24)

[LauPro]

Om dit 'probleem' op te lossen moet men denk ik het protocol aanpassen en de zaak omdraaien: stuur een RSS-feed naar de client zodra deze geüpdate is. Met daaraan een systeem zodat je je kan abonneren op verschillende feeds. Dan wordt er alleen data opgehaald als er echt iets nieuws is en niet stevast elke 10 minuten een feed van 200 KB.

[Verwijderd]

Dat push systeem lijkt me niet eenvoudig te implementeren, internet is nu eenmaal een pull systeem. Handiger zou zijn om alleen de veranderingen door te sturen ipv de totale feed. Simpelweg de (tijd)code van de vorige feed meegeven en de server kan de juiste veranderingen terugsturen.

[Fuzzillogic]

Yup, a la usenet.

Come to think of it, waarom dan niet usenet ervoor gebruiken?

[Verwijderd]

Je zou er aan kunnen denken om een tag in te bouwen waar je zegt wat je update-rate is en dingen als content expiration per item.

Is er al:

ttl stands for time to live. It's a number of minutes that indicates how long a channel can be cached before refreshing from the source.

<ttl>60</ttl>

[Verwijderd]

Zeer scherpe opmerking ! Is een ideaal medium daarvoor alleen hoe krijg je het "makkelijk" op usenet.

Dat caching noodzakelijk is voor RSS feeds is natuurlijk geen rocketscience, probeer eens 3x per 5 minuten slashdot op te halen, die heeft een customfeed voor je: "you are not able to receive anymore feeds for the next 48 hours"

Je zou er aan kunnen denken om een tag in te bouwen waar je zegt wat je update-rate is en dingen als content expiration per item. skipHours en skipDays bestaan, maar ik vraag me af in hoeverre aggregators daarmee rekening houden.

[Verwijderd]

Kunnen we niet in plaats van usenet, een torrent gerelateerde oplossing bedenken? het zijn maar kleine files en je verspreid de bandbreete over alle mensen die het willen

[ILUsion]

@Hiro Shima:
dat lijkt mij niet handig:
RSS is een nieuwsstandaard, en de wereld staat niet stil.
Met Torrent kun je wel statische bestanden doorsturen, maar als je RSS door Torent stuurt, krijg je naar alle waarschijnlijkheid een verouderde versie.
Een push-systeem is natuurlijk wel mogelijk, maar echt handig is het niet omdat je dan de server eigenlijk evenveel belast omdat niet-verstuurde berichten per gebruiker bijgehouden moeten worden en later doorgestuurd worden.
Een beter systeem ligt bij Usenet of zelf e-mail. Als je nu bijvoorbeeld vanbij de server een XML doorstuurt via e-mail met daarin de 10 laatste berichten als een gebruiker zich pas aanmeldt. Daarna gewoon een stukje XML met een tag erin "stukje XML nummer" en het bericht. Het enige dat er dan moet komen is een RSS-reader die je mail afscant ofzo...

[Room42]

[oeps]

[Verwijderd]

Dat zou op zich wel een aardige oplossing zijn. Maar er kleven wel wat nadelen aan een push-protocol. Je kan niet gewoon met IP-nummers werken. Er zijn immers zat mensen die achter een NAT-router zitten. Daar zijn (waarschijnlijk) ook wel weer oplossingen voor, maar dan moet je met gebruikersnamen oid gaan werken.

Het bandbreedte-probleem zou ook op te lossen zijn door gebruikers gewoon een hash te laten downloaden van het rss-bestand. En als die hash veranderd, dat ze dan pas het nieuwe rss-bestand downloaden. Een hash voor zoiets hoeft maar 16 of 32 bits (4 bytes) te zijn, dus veel minder dan een compleet rss-bestand. En natuurlijk (afhankelijk van het soort feed) niet toestaan het vaker te downloaden dan 1x in de 15 minuten.

[Verwijderd]

Het HTTP protocol heeft een ingebouwde caching method protocol order deel daarvan is een "If-Modified-Since" query. Gebruik die gewoon.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.25

[Fuzzillogic]

Klopt. Nadeel is wel dat je dat weer niet makkelijk via HTTP/webserver kunt doen. Abonneren is een idee, maar dat betekent dat je of continu een TCP-lijn open hebt staan (en dan raken ze snel op aan de andere kant), of je moet zelf een poort openzetten om die berichten te ontvangen en dus zit je weer met firewalls, security etc.

Maar het huidige systeem is idd niet echt ideaal.

[j.meijers]

Je kunt best een tcp-verbinding opzetten om de 10 minuten en dat daarna de server data stuurt als die er is. Dat is niet lastig hoor, heb je echt geen permanente TCP verbinding voor nodig.

Zegmaar, op dezelfde wijze als dat je je email checkt.

[AntiChris]

Das dus hetzelfde als elke 10 minuten een webpagina ophalen he, dat willen ze nou juist voorkomen.

[pietje63]

Dan kun je het ook via de e-mail versturen en als onderwerp zelf vast de tag [spam] voorzetten...

Als een pull systeem mogelijk is, dan krijg je spam en dat is wel het laatste wat je wilt... Ik denk dat het inbouwen van een systeem dat alle downloads logt en slechts 1 download per paar minuten ipv paar seconde genoeg bandbreedte bespaart.

Maar nu even iets meer ontopic .

Als ik dit systeem goed begrijp meot je voor het ophalen van de feeds dus altijd via de website

, zodat gebruikers steeds op de website moeten inloggen om hun favoriete feeds te lezen

surfen om de feeds te downloaden? Dan zijn automatische feeds toch helemaal niet meer automatisch verkrijgbaar? Ik snap het idee wel, op de site staan waarschijnlijk wat reclame advertenties wat de bandbreedte moet bekostigen..

[Verwijderd]

Of misschien alleen een MD5 checksum ofzo pullen. Als die anders is kun je een nieuwe feed aanvragen

[AntiChris]

Er is in HTTP gewoon een Not Modified message (304) hoor en de sites die dat niet gebruiken en toch zeuren moeten hun mond maar gaan houden en aan het programmeren gaan, want daar kunnen ze echt enorme winst mee halen.

[Verwijderd]

Eventueel te combineren met de proxyserver die toch bij vrijwel iedere provider staat.

Ook zou je nog een sourceforge-achtige constructie kunnen verzinnen dat content wereldwijd naar verschillende servers wordt gedistribueerd zodat je een server in de buurt kunt kiezen.

Terug naar de begintijd van HTTP toen er nog werd nagedacht over bandbreedtegebruik. HTTP lijkt alles te bieden om het probleem op te lossen.

[Verwijderd]

je kunt niet alleen een MD5 checksum pullen, want daar heb je het hele document voor nodig en dus is het bandbreedte probleem niet opgelost.

Handiger zou zijn als een "feed provider" zelf een file (e.g. feed.checksum) aanmaakt die de aggregator opvraagt, dat scheelt enorm in bandbreedte aangezien je alleen de checksum hoeft op te vragen, maar goed ook dit vraagt om een aardverschuiving in RSS wereld.

*edit*
de opmerking van AntiChris maakt het nog veel makkelijker....hmm eens in verdiepen !

[bartvb]

En zo'n push oplossing is er al:

www.pubsub.com

pubsub.com is een site die gebruik maakt van het PubSub protocol dat een onderdeel is van Jabber/XMPP (www.jabber.org)

Pull is idd gewoon enorm brak en super inefficient.

[sid3windr]

Iedereen hierboven die suggereert enkel de veranderingen te laten downloaden... Dit bestaat natuurlijk al een heel tijdje, in het HTTP protocol. In de headers kan je opgeven dat je enkel data wil doorkrijgen als het niet is gewijzigd sinds $tijdstip (zo werken vele http proxies). Probleem is dat de meeste rss clients dit niet gebruiken, of dat de meeste rss feed webservers dit niet ondersteunen.

*edit* whoops, ondertussen hadden al enkele personen het gezegd

[BoomSmurf]

Als ik het goed begrijp maken RSS feeds geen gebruik van If-Modified-Since, eTags en Content-Encoding?

Beetje snue van de makers... Zijn toch de eerste dingen die je implementeerd om bandbreedte te besparen? (Afgezien van eTags + GZIP combo die door Internet Explorer niet ondersteund wordt Probleem bestaat al sinds IE4 en nog steeds niet opgelost. Ook al zo sneu)

[LauPro]

dubbelpost

[Jerdenberg]

Misschien in de titel "pakt ... aan" of iets dergelijks gebruiken in plaats van het vreselijke anglicanisme "adresseert" (addresses zeker)?

[Olaf van der Spek]

laat eWeek nu weten dat een nieuw bedrijf hier handig gebruik van maakt om zijn diensten aan de man te brengen

En wat krijgt/wil dat bedrijf daarvoor terug?