h a l f b a k e r yGetting blown into traffic is never fun.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Teletext has been broadcast in a continuous loop, allowing content to be accessed fairly quickly. I propose that DAB stations be created with a similar function for the most popular recent local internet content, within limits determined by speed of access. This is not packet radio but DAB: there
is no interactivity.
The most popular content of the past week or so, possibly through a specific ISP such as BT in the UK, is broadcast and received by a DAB radio interfaced to a computer. The broadcast includes a list of IP addresses which are kept in a table. When the computer requests a particular file, rather than actually using the internet, it fetches the content from the broadcast itself.
This would increase available bandwidth by removing the clutter of the most popular content being fetched repeatedly by multiple clients, speed up access to the content itself and provide a limited, non-interactive copy of the internet which could be accessed if internet access itself was unavailable due to power cuts, acts of toddler or unpaid bills.
The limit would be determined by the length of the cycle required, bearing in mind that a number of DAB stations would be available for this purpose (yes i know that doesn't make sense).
A broadcast multimedia (Internet) system that uses DAB.
http://www.broadcas...78-6E0316410E678BC2
[Jinbish, Jan 31 2010]
ETSI specs...
http://www.worlddab...ing/standards_specs
Standards document "TS 101 498-1" goes through some specification for using DAB for website delivery.
(Not widely known, btw, unless you know what you're looking for!) [Jinbish, Jan 31 2010]
"Prefetching from a broadcast disk", Acharya, et. al.
http://ieeexplore.i...jsp?arnumber=492116
This paper (which is premium, I'm afraid) goes into the maths of the 'cycle' that [nineteenthly] points out. The motivations are for mobile, bandwidth limited, devices. [Jinbish, Jan 31 2010]
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Annotation:
|
| |
My Ph.D. basically proposed a very similar system, but with DVB and the addition of an 'Infostation' caching system: |
|
| |
Content -> (over DVB) -> Infostation (possible transcoding) -> (over WiFi) -> mobile devices. |
|
| |
The motivation here was to provide a better system for mobile video & multimedia by allowing mobile users to download such files over WiFi - thereby relieving the (over-burdened) cellular system. |
|
| |
There are very similar issues with your system. The 'cycle' issue is known as a 'carousel'. There is research on the subject that looks at various schemes to try and maximise the periodicity and available of the required content... Incidentally, the popularity of files tends to follow Zipf's law (that is the most popular is twice as popular as the next, which is twice as popular as the next etc.) |
|
| |
I basically argued that no-one watches TV at night (well - less people anyway) and that the capacity of a DVB multiplex (18Mbps) could be used for a couple of hours to broadcast web & multimedia to these infostation caches throughout a metropolitan area. This caching storage system somewhat alleviates the issue of 'what to broadcast'. |
|
| |
Thanks, [jinbish]. I thought there'd be a problem with using DVB because i imagined the system would be more complex than DAB. I know very little about this stuff. I have a vague intuition that there's some kind of self-defeating payoff between the duration of the cycle and the decluttering of the network. I thought about caching but since this is already done by web browsers, i don't see a speed advantage. Thanks for the links, good to know i'm not just crazy and lack of access to ATHENS is the bane of my life! |
|
| |
DAB is simpler than DVB from a reception point of view but both they are on a par when it comes to inserting data in them. |
|
| |
Pre-fetching is basically caching on your own device - it guesses what you'll want (based on file popularity) and then 'listens' to the broadcast cycle and saves the required file. The trade off is your own storage versus the waiting time of the cycle. Since that Achayra paper (1996), storage has become *amazingly* cheap and mobile. It's a couple of £ for a Gb USB, for example. I think that is closest to what you propose. |
|
| |
As far as saving the network the trouble of sending popular files multiple times, there are Internet caching systems (Content Distribution Networks). They alleviate traffic by recognising popular content and storing it so users don't have to go to the source (much like a mirror site). |
|
| |
As far as ATHENS is concerned - I feel your pain. Helps if you know someone that works at a Uni that has a subscription... ;-) |
|
| |
I'm not going to go on about ATHENS too much because it's inappropriate here, but possibly the one single thing which could make the biggest difference to herbalism's reputation in these islands would be us all being able to access it rather than, i presume, the people at Lincoln and Exeter. I'll make a more relevant anno in a bit! |
|
| |
Here's a more relevant anno: |
|
| |
So the iPlayer accounts for ten percent of UK bandwidth? In that case, more than ten percent of the UK's internet content is right now being transmitted via DVB ("more than" because of the other TV channels). If that were constantly cached locally, perhaps even in one's own home, that would cut out maybe an eighth of the demand on bandwidth in one go. ISPs here are unhappy with the iPlayer's demand on bandwidth as it stands. |
|
| |
So, this is creeping featurism of course, but two things can happen. One: cache the BBC's output and rebroadcast on different schedules if demanded using domestic devices which ultimately form some kind of network (but not a packet-based one). That can be subtracted from the bandwidth. At the same time, use a separate DAB frequency to deal with other kinds of content such as, dare i say, Bit Torrent, YouTube and bits of popular websites such as Wikipedia and Google. |
|
| |
I'll look into Zipf because it rings a bell but isn't currently in my head. Thanks! |
|
| |
You geeks are so damned awesome! A tiny tear of pride on
your bun. |
|
| |
I haven't even got onto the challenges raised by media types &
one-way broadcast transmission and errors... |
|
| |
Mm, well naively i suppose i fondly imagine something doubtless hopelessly primitive like a CRC plus comparison of two copies of the same file might help. |
|
| |
[Ian], that's really disappointing, isn't it? Reminds me of the horror i felt when i realised there was no connection between the retail price index and exchange rates and that therefore the global economic system was in fact really quite ill. |
|
| |
Oh, and the other thing is that i've just realised this could break Bit Torrent completely. |
|
| |