Morpheus feature: partial files from multiple users

from Gerald Oskoboiny <[email protected]>, Tue, 24 Jul 2001 05:05:12 -0400

Replies:

hugo
danbri

Parents:

None.

I am way out of touch with the current capabilities of
Napster/Gnutella/etc clients, but just saw this:

> After you select the file to download, Morpheus uses
> Fast Stream technology to piece together the same file
> from multiple users.

Excellent, I'm glad someone is doing this! I was hoping someone
would. Hopefully similar features will make it into other clients
as well. (they may be there already, I dunno)

that's from:

Review: Morpheus (Music City)
By Colin Stoner 5/29/01
http://www.mp3newswire.net/stories/2001/morpheus.html

found via
http://www.mp3newswire.net/stories/2001/topclones.html
(Morpheus is the top download on CNet)

the rest of the Morpheus review:

> Ease of Use: XXXXX
>
> This is a very simple program to use, and I guarantee that any
> level computer user can figure out this program. One reason that
> it is so simple to use is that it integrates Microsoft programs
> (Windows Media Player and Internet Explorer mainly) to give it a
> familiar feel to all users. There are five main areas of the
> program that you can navigate: Start (MusicCity.com homepage), My
> Media (files you are sharing over Morpheus), Theater (watch
> movies that you are sharing), Search (search the Morpheus Network
> for files) and Traffic (monitor current uploads and downloads on
> your computer). All sections are easily found at the top of the
> program and are accessible at any time when Morpheus is running.
>
> Layout/Design: XXX
>
> Morpheus has a very organized layout. It splits the window into
> three different frames (top, left and right), which allows for
> quick and easy navigation. However, the design lacks any real eye
> candy (however I am a fan of the logo). I assume that the bland
> design can be attributed to the MusicCity boasting that Morpheus
> will use a maximum of 10% of your system resources. Keeping the
> flashy colors and window fly-bys to a minimum will help the
> program (and your computer) run smoother.
>
> Speed of Download: XXXXX
>
> This is where Morpheus leaves it�s mark on the Peer-to-Peer file
> sharing world. When you search for a file, Morpheus replies with
> all the users that have the file you requested. Nothing special
> yet, it happens when you download. After you select the file to
> download, Morpheus� uses Fast Stream� technology to piece
> together the same file from multiple users. This doesn�t mean
> that your 56k modem can now download at unthinkable speeds,
> instead it helps keep the upload bandwidth down and keeps the
> download speed the same. It�s almost as if MusicCity watched a
> full season of Barney, and came out saying that �Caring Means
> Sharing...bandwidth!� All users benefit from this system, even
> the people with @Home cable (remember, you have a 12k bandwidth
> cap) or a xDSL line.
>
> Overall: XXXXX
>
> Hands down the best search program I have ever used. This thing
> dwarfs any Gnutella client program; makes Imesh look silly and
> even takes a wonderfully relieving steamer on Napster. It is easy
> to use, easy to find the file you�re looking for and isn�t
> limited to just MP3s. You can download video, images, documents
> and software and they are as easy to find as MP3s. The only
> problem with the program (and it�s not MusicCity or Morpheus�
> fault) is that there are not a lot of users on it yet. For
> example, it�s 3 am in Seattle right now and a search for
> Radiohead turns up nothing but one version of Creep (Acoustic).
> People, you need to download this ASAP and get it loaded instead
> of Napster or any other file-swapping client while it�s still
> able to duck the RIAA�s radar. This program should not go
> unnoticed and unused.
>
> Colin Stoner is a regular contributer to MP3 Newswire. Colin is
> also the editor of Experience-Mp3.com.

--
Gerald Oskoboiny <[email protected]>
http://impressive.net/people/gerald/

Re: Morpheus feature: partial files from multiple users

from Hugo Haas <[email protected]>, Wed, 1 Aug 2001 17:59:46 -0400

Replies:

None.

Parents:

gerald

* Gerald Oskoboiny <[email protected]> [2001-07-24 05:05-0400]
> I am way out of touch with the current capabilities of
> Napster/Gnutella/etc clients, but just saw this:
>
> > After you select the file to download, Morpheus uses
> > Fast Stream technology to piece together the same file
> > from multiple users.
>
> Excellent, I'm glad someone is doing this! I was hoping someone
> would. Hopefully similar features will make it into other clients
> as well. (they may be there already, I dunno)

I am never very enthusiastic about such optimizations (see my position
on download accelerators[1]).

This one is slightly different from download accelerators. My point
about download accelerators was that as soon as everybody uses them,
the actual bandwidth that people will get will be lesser than
bandwidth they would have gotten if nobody used download accelerators.

Here, if this feature is implemented in Web browsers for example, it
means that load balancing using e.g. DNS round-robin will not be
effective at all. By adding servers in your mirroring system, you will
decrease the download time for users, but not decrease the load; well,
in a sense, transactions will be shorter, so the load will be lower,
but for cases were there are a lot of connections simultaneously (the
publication of the XHTML 32 Recommendation), the Web site
administrators lose, and therefore all the users lose at the same
time.

I like single TCP connections. :-)

What I would like to see would be a way to automatically download
something from the "fastest" (lowest latency and/or highest bandwith)
mirror available.

1. http://impressive.net/archives/fogo/[email protected]
--
Hugo Haas <[email protected]> - http://larve.net/people/hugo/
I love it when a plan comes together! -- John "Hannibal" Smith

Re: Morpheus feature: partial files from multiple users

from Dan Brickley <[email protected]>, Sun, 7 Oct 2001 08:52:46 -0400 (EDT)

Replies:

None.

Parents:

gerald

On Tue, 24 Jul 2001, Gerald Oskoboiny wrote:

> I am way out of touch with the current capabilities of
> Napster/Gnutella/etc clients, but just saw this:
>
> > After you select the file to download, Morpheus uses
> > Fast Stream technology to piece together the same file
> > from multiple users.
>
> Excellent, I'm glad someone is doing this! I was hoping someone
> would. Hopefully similar features will make it into other clients
> as well. (they may be there already, I dunno)
>
> that's from:
>
> Review: Morpheus (Music City)
> By Colin Stoner 5/29/01
> http://www.mp3newswire.net/stories/2001/morpheus.html
>
> found via
> http://www.mp3newswire.net/stories/2001/topclones.html
> (Morpheus is the top download on CNet)
>
> the rest of the Morpheus review:

[snipped]

So I've been using Morpheus a bit, from a Windows box. Semi-structured
notes / brain dump follow...

Main reaction: I'm slightly baffled as to why the partial-file feature
seems to be considered a proprietary fancy feature, when HTTP/1.1 itself
allows you to request byte-ranges. Kudos to them for actually
implementing and exploiting it interestingly though. Shame there's no
linux client too; not sure if that's because the protocol is considered
proprietary, or because Morpheus/Kazaa form a closed (weakly) ACL'd
network. Either way it isn't hard to talk to a Morpheus installation --
they're just using a subset of HTTP with a few additional
conventions.

After bit of rummaging, it emerges that a running Morpheus installation
opens up a public webserver on port 1214 of your machine. The root page is
a plain (no metadata; that must be elsewhere) HTML directory of the shared
files you're exposing. And it seems to respect the same HTTP headers for
byte ranges that work on my Apache server:

Forzample:

#!/bin/sh
RES=http://koolaid:1214/13221/dead_kennedies-moon_over_marin.mp3
lwp-request -U -e $RES -H 'Range: bytes=3-140'

..grabs a chunk of some MP3. There can't be much more to what they're
doing apart from a metadata exchange convention. I assume the 'super
peers' to the query routing work.

The HTTP server also leaks out some other data:

danbri@fireball:~ > HEAD http://koolaid:1214/|more
501 Not Implemented
Client-Date: Sun, 07 Oct 2001 12:28:41 GMT
Client-Peer: 10.0.2.19:1214
X-Kazaa-IP: 10.0.2.19:1214
X-Kazaa-Network: MusicCity
X-Kazaa-SupernodeIP: 211.108.87.42:1214
X-Kazaa-Username: dan_bri

...this gives the address of another node, which seems to be another user
rather than some big Napster-esque central server.

danbri@fireball:~ > HEAD http://211.108.87.42:1214/
501 Not Implemented
Client-Date: Sun, 07 Oct 2001 12:32:14 GMT
Client-Peer: 211.108.87.42:1214
X-Kazaa-IP: 211.108.87.42:1214
X-Kazaa-Network: MusicCity
X-Kazaa-Username: xyz1333(*)

So... once you know the address of a Morpheus node, you can get a list of
the resources it shares; and you can get byte-ranges of the thing itself.
The accompanying HTTP headers also include a bunch of metadata including
what seems to be some kind of digest:

danbri@fireball:~ > GET -e -d -S http://koolaid:1214/13221/dead_kennedies-moon_over_marin.mp3
GET http://koolaid:1214/13221/dead_kennedies-moon_over_marin.mp3 --> 200
OK
Connection: close
Date: Mon, 01 Jan 1990 19:32:40 GMT
Accept-Ranges: bytes
Server: KazaaClient Aug 29 2001 19:44:27
Content-Length: 3551358
Content-Type: audio/mpeg
Last-Modified: Mon, 01 Jan 1990 19:32:40 GMT
Client-Date: Sun, 07 Oct 2001 12:40:53 GMT
Client-Peer: 10.0.2.19:1214
X-Kazaa-IP: 10.0.2.19:1214
X-Kazaa-Network: MusicCity
X-Kazaa-SupernodeIP: 211.108.87.42:1214
X-Kazaa-Username: dan_bri
X-KazaaTag: 5=222
X-KazaaTag: 21=128
X-KazaaTag: 6=DEAD KENNEDIES
X-KazaaTag: 4=Moon Over Marin
X-KazaaTag: 3==sTgebvBMqgbtsBuYifzzJXBktLk=

I'm not sure how to get the metadata on its own (per resource, or per
server), nor how they're dealing with searching. I'd like to know just
enough about what they've done to understand what the server it opens up
on my laptop is doing, and enough so that I can query/search/etc my
Morpheus'd laptop from a linux box. I couldn't find much info by Google.

Has anyone else on fogo taken a look? Shouldn't be a big job for anyone
who knows how to use tcpdump etc properly...

danbri

ps. HTTP spec on range requests:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

(*)I changed this, in a pathetic nod towards stable-door-bolting privacy