It's ihug's new name for starnet/satnet. See:
Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/
"Inside me Im Screaming, Nobody pays any attention." | eMT.
Due to impending global destruction and the extinction of all life,
access to international sites may be interrupted.
We apologize for the inconvenience.
To quote from the IDG web page
>Ultra will also leverage Ihug's work on multicast services in the past
>year, which has already been enthusiastically received by SatNet customers.
>Wood says newsgroups, email and "favourite Web pages" will be delivered via
>multicast, to be followed by streaming audio and video, and rental software.
Just a couple of notes,
1) IHUG have been promising multicast news and email services since the start
of offering satnet services ( every second month IHUG promised 24/7 email
offline service NEXT month ), and only made its development a priority
after november 1999.
2) Someone not a million miles from this keyboard ( OK, yes thats me folks )
suggested this on august 1999 as an alternate technical solution to the
introduction to the statnet datacap ( volume charging )
To quote myself on ihug.satnet.nz
<On 13 Aug 1999 15:55:27 GMT, David Mohring
><On Sat, 14 Aug 1999 02:28:49 +1200, Troy Krajancic
>>David Mohring wrote:
>>> - Quote Ted
>>> >Multicast transmissions (coming real soon now) are not associated with your
>>> >IP address and hence you will not be charged for any multicast data that
>>> >you may receive.
>>> - Unquote Ted
>>How does it work with my client software? My newsreader uses TCP, a point
>>to point connection protocol.
>This would work as another driver ontop of the satnet card hardware drivers.
>The main internet multicast standard is MBONE
>IHUG could run its own local MBONE broadcast over both the
>skytower and sat satnets.
>MBONE uses a different set of protocols/interfaces on
>top of which you can run a large set of clients
>( note the the Multicast Proxy System in the last URL )
>The best solution would involve proxy servers for each service
>on the users satnet connected computer.News, Email, Web,
>and ( yippee ) ftp/Archive Syncronize. A client
>program would run 24hrs/7days caching/mirroring
>preselected items. A small web based interface
>(http://localhost:8081/) would control the proxy.
>The server would checksum each chunk/2k of item and
>the proxy would re-request any failed chunks.
>How would this work for your news reader?
>1) yourbrowser( http://localhost:8081/newsgroups )
> preselect any news groups you want a full/partial feed
> and the size of cache diskspace allocated to that newsgroup
>2) yournewsreader( newshost=localhost:119 ) -> localhost-NNTP-proxy-client
> localhost-proxy-client :
> look up group/header/article in local cache
> found: send to yournewsreader
> notfound: connect to internet and get it
> either requesting it via IHUGs satnet MBONE
> or directly from news.*.ihug.co.nz
>Email would work the same as newsreader but would transmit
>How would this work for your websurfing?
>1) yourbrowser( http://localhost:8081/websites )
> preselect any websites + webclass you want a full/partial feed
> ( a webclass is website/subdirectory yahoo type classification)
> and the size of cache diskspace allocated to that item
>2) yourbrowser( httpproxy=localhost:8080 ) -> localhost-HTTP-proxy-client
> localhost-http-proxy-client :
> look up page/item in local cache
> found: send to browser
> notfound: connect to internet and get it
> either requesting it via IHUGs satnet MBONE
> or directly from the proxy at IHUG
>How would this work for your local mirror of ftp sites
>1) yourbrowser( http://localhost:8081/ftpsites )
> preselect any ftp URL for files or directories
> name the directory on your drive where you want the mirror put.
>2) Connect to the internet an request it via IHUGs satnet MBONE.
The actual implementation does not use MBONE or a web based interface
but does work just as described.
to quote from the IDG web page
>"As time goes by we'll add more and more of that kind of content, because
>we think that local broadband content is a key element to this kind of
>service," says Wood.
He is not wrong, broadcast internet is the future.
David Mohring -Imagine such a service using saturn cable or even sky digital.
Actually it's a new brand name for the new broadband products
that will be rolled out over the coming months including
high speed Internet, Digital TV, datacasting, multicasting,
asp applications etc.
David Mohring - When?
The multicasting service is available 24/7 right now..whats your
point. If it's more horn blowing then...oh o.k. David. As was
explained subsequent versions of Windows caused the whole project
to be redone as Microslut killed the ability to multicast onto
98/2000 platforms. The new gateways BUILT and DESIGNED by us
are shortly to be shipped to the USA so that the DBS customers
can get the same service. Jesus wept mate were building cutting
edge equipment and designing complicated software and it takes
time. Ultra is set to be released to the public on the 9th of
July and has already been released to 2000 long term customers.
It might have been ( and IMHO will work far better ) to have offered
the service to uses by providing them with pre-configured cut down
linux/BSD boxes working as gateway,firewall and muticast-proxy-clients.
These could be remotely administered (set/forget) via IHUG.
>The new gateways BUILT and DESIGNED by us
>are shortly to be shipped to the USA so that the DBS customers
>can get the same service. Jesus wept mate were building cutting
>edge equipment and designing complicated software and it takes
I know the technical team have made great progress since the IHUG
management made it a priority in november 1999.
>Ultra is set to be released to the public on the 9th of
>July and has already been released to 2000 long term customers.
Will you be offering a deal to existing satnet customers to
uprade the old cards?
It would have been a lot easier if you had focused on using
existing open protocols/code (MBONE), a lot of the groundwork had already
been done in europe. See
David Mohring - "If people didn't complain, nothing would change"
When we started the project there was no existing work available on
multicast Usenet with no back channel. As far as I know there still
isn't. Most of the existing proposals for multicast protocols,
including those used on the MBONE, are irrelevant to us since they
require the presence of a back channel for address allocation,
traffic management, etc.
I can't see anything relevant there. What was your point?
Ross Smith <ros...@ihug.co.nz> The Internet Group, Auckland, New Zealand
"So that's 2 T-1s and a newsfeed ... would you like clues with that?"
-- Peter Da Silva
>Actually it's a new brand name for the new broadband products
>that will be rolled out over the coming months including
>high speed Internet, Digital TV, datacasting, multicasting,
>asp applications etc.
You'll have to fire him Tim. Terminate his account - this
misinformation of his has to stop!
"We have made you a creature neither of heaven nor of earth, neither mortal nor immortal, in order that you may, as the free and proud shaper of your own being, fashion yourself in the form you may prefer." - Pico della Mirandola
*Email:* corum.usenet@apexmail . Note: you must add .com to the end for this to work. No timewasters.
*All my comments are "In my Opinion", unless otherwise stated. All trademarks, copyrights, etc. remain property of their owners. E&OE.
Quote Emmanuel Duros's home page
>Integration of Broadcast Satellite Networks in the Internet
>Broadcast satellite networks can access an area potentially
>spanning nations and provide high bandwidth services independent of
>the user's location . Integrating broadcast satellite networks in the
>Internet is therefore an important issue because they can bypass
>bottlenecks offering high-speed transmission over long distances.
>However, this type of network is by nature unidirectional and is
>not supported by common routing protocols. Routing protocols
>assume that links are bidirectional and therefore routers connected to
>an "outgoing" unidirectional link cannot be aware of the
>existence of networks reachable through this link.
>I have been designing and implementing mechanisms in order to
>support unidirectional links (e.g. broadcast satellite networks) in the
>Internet. Basically, there are two approaches, the first one is to
>modify routing protocols to take into account unidirectional links, the
>second one is to set up link layer tunnels between receivers and feeds.
>The latter emulates below IP level a bidirectional connectivity
>in the presence of a unidirectional link: a receiver can send routing
>messages (through link layer tunnels) to feeds without having to
>provide modifications to routing protocols.
He has been working on this since 1996, and had a working trial MBONE
( minus error correction ) of satnet DBS back in Feb 1998.
The result is part of the upcoming draft internet standards. see
As I mentioned back in August, the MBONE protocols plus servers and
clients source code is open and freely available, for all platforms.
It would represent a stable starting point. The source code could be
quickly adapted to "going backless" ( nice for dancing )
David Mohring -The internet succeeds because ALL the protocols are OPEN
Have you actually read that paper? It is *not* about one-way
broadcasting. Like all other multicast protocols I've seen, it assumes
the availability of a back channel. It's about encapsulating two-way
IP traffic over asymmetrical connections, in which one side of the
channel is multicast and the other a conventional IP link. This is
all completely irrelevant to what we're doing.
> As I mentioned back in August, the MBONE protocols plus servers and
> clients source code is open and freely available, for all platforms.
> It would represent a stable starting point. The source code could be
> quickly adapted to "going backless" ( nice for dancing )
Do you actually think adapting code written for a two-way network to
run on a one-way network is that easy? What colour is the sky on your