"slatconsulting" <oj...@yahoo.com> wrote in message
news:Xns94298D53736...@140.99.99.130...
Yes, "remotely queued 1" mean that you're next in line. If
someone gets a movie from me, start to finish, that could take
12 hours or more, if they are the ONLY one with whom I'm
sharing! With 3 open slots, 36 hours. If the video is larger
than normal ... Need I say more.
BJ
I've just begun using the program also & I'm not at all impressed. After 12
hours I've downloaded not a single byte yet I'm being uploaded from left
right & center. Also, yesterday I was queued "4" but now the exact same file
shows my position to be 53(!!)
How is this program "better" than Kazaaa? So far it's awful.
--
Paul
I couldn't agree more. I've gone from "1" to "95" in a blink of an eye. It
seems totally arbitrary at times. If you're downloading music or jpegs,
WinMx is serviceable. But mpegs or video? Forget it.
Actually, it was 5 minutes!
MX polls the sources of your queued items every 5 minutes. If
no response is received in the next 90 seconds, your position
times out. (These times can not be modified in settings).
If, in the interval, your spot in a queue was cancelled, either
by the user, or because of primary shifting, or an actual TCP
time-out and the source is still reachable in the next poll, you
will get added back in at the end of that queue. Since your
display is only update after the 5 minutes elapses, it appears
instantaneous to you.
If you are present when a queued item turns red (which can be
for several reasons), you can generally restore your queue
position by "retry"ing the source entry. This is especially
true for video queues as they are slow moving, so restoration
can often occur 15 minutes or more after the item has gone red.
The thing to bear in mind is that the network is somewhat
nebulous. There are many reasons why a queue position can be
interrupted (it is not really a connection, just a status). The
most typical seems to be a primary dropping out somewhere in the
UDP path, it also seems (at least to me) that many users opt for
primary status who simply do not have the horsepower to do so.
When connected thru one of these, status packets disappear into
the ether!!
While Kazaa suffers from none of these problems, its users seem
to be exposed to the thorn on the rose bush a tad more than Gnu
type networks.
BJ
> it also seems (at least to me) that many users opt for
> primary status who simply do not have the horsepower to do so.
Or they only stay online for a short period of time. Perhaps in the next
version primaries will only be used for searching, leaving que
responsibility entirely to the servers. Or would this create more problems
than it would solve?
==========
How would Frontcode run such queue servers and at the same time disavow
knowledge of user activities on WPN?
Don
WinMX doesn't HAVE central servers. Central servers were Napster's
downfall. WinMX's lack of central servers are how they have been able to
survive the RIAA's goons
So yes, it would create more problems than it would solve...
> WinMX doesn't HAVE central servers. Central servers were Napster's
> downfall. WinMX's lack of central servers are how they have been able to
> survive the RIAA's goons
>
> So yes, it would create more problems than it would solve...
ooops I will rephrase, bad choice of words on my part.
Would removing primaries from que management, or simply making it direct
peer to peer (no primary middleman), would that help or hurt? Im thinking
in terms of people who are already qued. In this case, why should a primary
dropping off matter? It has always been this way I think... but what is the
benefit?
A primary provides added security vs RIAA snoops. Your peer doesn't know
your IP address until a transfer is started.
Don
Most assuredly true, Don. But add to that thought that, without
primaries, firewalled users would be unable to share - as the
primary negotiates the reversal of the TCP flow for them.
Also without primaries or servers, meaning that ALL traffic is
p2p or daisy chained, I'm hard pressed to envision a search or
browse scheme that works in a timely fashion for more than the
smallest of sub-nets.
BJ
> Most assuredly true, Don. But add to that thought that, without
> primaries, firewalled users would be unable to share - as the
> primary negotiates the reversal of the TCP flow for them.
>
Do other p2p programs mask clients in this fashion?
> Also without primaries or servers, meaning that ALL traffic is
> p2p or daisy chained, I'm hard pressed to envision a search or
> browse scheme that works in a timely fashion for more than the
> smallest of sub-nets.
Security issues asside... perhaps then primaries should be limited to
searches only?
Coming full circle (or, perhaps just closing the loop;-0)
consider:
Under the present design, primaries should, if possible, be
limited to only those machines and connections which can truly
perform the task! I would go so far as to say that an
underperforming primary should be dropped forcefully and
immediately to secondary status without recourse.
The problem so far of weak primaries, as I see it, is simply the
STUPID user feeling that it is somehow better to be one, without
a clue as to what the function is.
MX's set up leads one in this direction, I suppose. But to some
extent I blame this group for having espoused the be-a-primary
mentality to all new visitors seeking help (probably the very
first clue that they should not be). If I've contributed
anything here, I hope it is a nudge away from that page in the
hymnbook!!
Hmmmm, I need to get out more;-0)
BJ
Theo wrote:
> "Billy Joe" <check_...@this.is.invalid> wrote in news:sKxqb.2743
> $gn1.5...@news1.news.adelphia.net:
>
>> Most assuredly true, Don. But add to that thought that, without
>> primaries, firewalled users would be unable to share - as the
>> primary negotiates the reversal of the TCP flow for them.
>>
>
> Do other p2p programs mask clients in this fashion?
>
===========
Probably some variations of, there must be only so many ways to design an
usable decentralized system. OTOH, some don't seem to mask at all. From
what I remember of Limewire and BearShare (Gnutella clients) users were
identified by their IP addresses instead of handles, and AFAIK, some of the
userIDs on eMule contain user's IP address.
I'm paranoid enough not to use any p2p application that is open source or
that I know has been reverse engineered. If anyone has access to the
protocol and knows how to write a client to bring users together on a given
network, the RIAA can too. I don't know who is behind Kazaalite, for
instance, never saw that question asked in depth like it is of ES5. Someone
in Russia or Poland? Great. All I hear is people saying it's spyware free.
Besides, add-ons such as KaZuperNodes can easily associate supernode
usernames to their IP addresses, so you won't see me on Fasttrack.
Thus IMHO, a p2p program may be masking clients, but little good it does if
other clients or add-ons exist on the same network dragging them out of the
closet.
That is that, just an opinion, not accsuing Kazaalite of being work of the
RIAA or claiming that Gnutella & eMule are less safe than WinMX.
Don
> That is that, just an opinion, not accsuing Kazaalite of being work of
> the RIAA or claiming that Gnutella & eMule are less safe than WinMX.
I thought I heard that kazaalite just replaced a adware dll with a fake
one. Maybe there is more to it.
=========
For one thing, kazaalite has allowed users to search for bitrates higher
than 128k when kazaa proper did not (I don't know whether it can nowadays).
Granted, a simple registry change could have done that. But then I don't
think a 3MB+ installation package would be needed for a dummy file and
registry change.
Another thing (I'm not advocating going easy on ES5): all the suspicion
surrounding "ES5 from Palestine" while nomad kazaalite doesn't seem to
bother people ("ok, I get it from site A in Timbuktu today? Thanks.")
Don