myster-general Mailing List for Myster Open Source

Does anyone know why we had 535 downloads on the developer site on the 10th?
We usually only have 10-50 a day...

dear myster developer team.

i have give up to support myster's localization.
please exclude me from developer list.
because japanese users decreased too much.
very sorry...

good bye and cheers,
heavy baby

__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!
http://bb.yahoo.co.jp/

Hi,

Congratulation!
Myster is completely original.
UTF-8 multi language.
Speedy search Speedy transfer.
and Simple interface!

cheers,
heavy baby

__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!
http://bb.yahoo.co.jp/

Mystery solved. The spike of activity on the sourceforge page was caused by
myster being included on the Mac Addict CD-ROM.

http://www.macaddict.com/

Mac Addict is one of the biggest Mac magazines in north America. We are
included on the CD included with their February edition. This edition
started arriving last week sometime.

On 1/13/03 12:49 PM, "425...@sn..."
<425...@sn...> wrote:

> On Mon, 2003-01-13 at 12:17, andrew (addertheblack)
> andrew-at-mysternetworks.com |sourceforge/1.0-Allow| wrote:
>> On 1/13/03 5:14 AM, "heavy baby" <hea...@ya...> wrote:
>> 
>>> To filter local IP & Private IP
>>> Is this effective?
>>> 
>>> * com/myster/tracker/ui/MysterIP.java
>>> 
>>> if (ip.equals("127.0.0.1")) throw new Exception("IP is local host.");
>>> 
>>> if (ip.equals("127.0.0.1")||ip.equals("0.0.0.0")||ip.startsWith("192.168"))
>>> throw new Exception("IP is local host or private.");
>> 
>> 
>> Hanggon.. why do you want to filter private ips? so the computers on your
>> LAN don't appear?
> 
> The first issue is : Whether or not myster searches the local LAN's for
> file should be an option. At Kathryn's, there are three computers
> running Myster. I know very the mp3 collections available on these
> machines. I do not want to search them. Inversely, if I got people here
> at the university to run Myster, then I would want to search their
> collections as well.

ok.

What if you own half of them.. Most of the servers on the lan are yours but
one isn't and you still don't want to search your own...?

> The second issues is : you should ensure  that local ips are not being
> broadcasted outside -- this would be considered a security weakness.

They are being sent in the tracker as top ten.

I would need to check to see if the socket the TCP connection is on is on a
LAN connection or not.

> You
> have to work to make sure that computer with local-ips can still be
> search, even though outsiders do not actually know their ip. If they
> know the ip of the firewall/proxy, they will have to do with that.

On Mon, 2003-01-13 at 12:17, andrew (addertheblack)
andrew-at-mysternetworks.com |sourceforge/1.0-Allow| wrote:
> On 1/13/03 5:14 AM, "heavy baby" <hea...@ya...> wrote:
> 
> > To filter local IP & Private IP
> > Is this effective?
> > 
> > * com/myster/tracker/ui/MysterIP.java
> > 
> > if (ip.equals("127.0.0.1")) throw new Exception("IP is local host.");
> > 
> > if (ip.equals("127.0.0.1")||ip.equals("0.0.0.0")||ip.startsWith("192.168"))
> > throw new Exception("IP is local host or private.");
> 
> 
> Hanggon.. why do you want to filter private ips? so the computers on your
> LAN don't appear?

The first issue is : Whether or not myster searches the local LAN's for
file should be an option. At Kathryn's, there are three computers
running Myster. I know very the mp3 collections available on these
machines. I do not want to search them. Inversely, if I got people here
at the university to run Myster, then I would want to search their
collections as well.

The second issues is : you should ensure  that local ips are not being
broadcasted outside -- this would be considered a security weakness. You
have to work to make sure that computer with local-ips can still be
search, even though outsiders do not actually know their ip. If they
know the ip of the firewall/proxy, they will have to do with that.



-- 
  "In Google non est, ergo non est." 

- Guillaume

On 1/13/03 5:14 AM, "heavy baby" <hea...@ya...> wrote:

> To filter local IP & Private IP
> Is this effective?
> 
> * com/myster/tracker/ui/MysterIP.java
> 
> if (ip.equals("127.0.0.1")) throw new Exception("IP is local host.");
> 
> if (ip.equals("127.0.0.1")||ip.equals("0.0.0.0")||ip.startsWith("192.168"))
> throw new Exception("IP is local host or private.");


Hanggon.. why do you want to filter private ips? so the computers on your
LAN don't appear?

On 1/13/03 5:14 AM, "heavy baby" <hea...@ya...> wrote:

> To filter local IP & Private IP
> Is this effective?
> 
> * com/myster/tracker/ui/MysterIP.java
> 
> if (ip.equals("127.0.0.1")) throw new Exception("IP is local host.");
> 
> if (ip.equals("127.0.0.1")||ip.equals("0.0.0.0")||ip.startsWith("192.168"))
> throw new Exception("IP is local host or private.");

I forgot to mention. This will only stop these ip ranges from being added
into the tracker. They will still be searched. To change that you need to go
poking around in the crawler settings..

This setting will have to be put into a preferences panel since there are a
few people who use Myster only on LANs.

On 1/13/03 5:14 AM, "heavy baby" <hea...@ya...> wrote:

> To filter local IP & Private IP
> Is this effective?
> 
> * com/myster/tracker/ui/MysterIP.java
> 
> if (ip.equals("127.0.0.1")) throw new Exception("IP is local host.");
> 
> if (ip.equals("127.0.0.1")||ip.equals("0.0.0.0")||ip.startsWith("192.168"))
> throw new Exception("IP is local host or private.");

nope.

There are 3 blocks of addresses revered for LAN usage.

<http://en.tldp.org/HOWTO/IP-Masquerade-HOWTO/addressing-the-lan.html>

The place is correct in the code.

To filter local IP & Private IP
Is this effective?

* com/myster/tracker/ui/MysterIP.java

if (ip.equals("127.0.0.1")) throw new Exception("IP is local host.");

if (ip.equals("127.0.0.1")||ip.equals("0.0.0.0")||ip.startsWith("192.168"))
throw new Exception("IP is local host or private.");

cheers,
heavy baby

__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!
http://bb.yahoo.co.jp/

> Any arguments about the fairness of polling are ridiculous.

ok. i give up ##
hv

__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!
http://bb.yahoo.co.jp/

On 1/10/03 12:09 AM, "heavy baby" <hea...@ya...> wrote:

> i'm afraid of server side queue.
> if server side queue are supported...
>   the people A who has many files will get grows grows.
>   the people B who has poor files will not get grows.
>   gulf of wealth and poverty probably will be widens.
>   because A will never let upload to B.
>  you see this dirty situation in WinMX most popular in japan.
>  WinMX uses server side queue!
>
> if client side queue are supported...
>  everyone will get chance to download!
>  everyone will be equality!
>  and Myster will be true filesharing client.
>  this is freedom that i believe.

If there is no queue on the server then when a client tried to connect he
will only get a busy signal or downloading spot.

If you have only only a busy signal or a download spot you're dead. There's
not way of doing queuing. The only thing possible is polling.

Downloader A tried to connect, get a busy, retried a few seconds later.

polling sucks. It's not "fair" in the Computer science sense of the word.
That is there's no guarantee that Downloader A will EVER get a chance to
download.

Download A is continuously retrying. He has been re-trying for an hour.
Downloader B comes along. Just before his first attempt a download spot
becomes free. Download B then tries and can connect. Downloader A keeps
retrying. This is polling. This is what happens on FTP servers. This sucks.

What people try to do on FTP server is have the re-try period as short as
possible. Like 0. That way they have more chance of getting the file. This
put a tremendous strain on the FTP server. If you have enough people doing
this, you have a DoS attack! This is polling. Polling sucks.

Have the client queue their own transfers does nothing for you. Clients are
only aware of their own downloads.

Client side queuing != server side queuing. They have totally different
goals. Saying "I don't like one I like the other" is like saying, I don't
think sports cars are practical vehicles I'll use an orange instead. Client
side queuing is a convenience. It automatically stops you from downloading
two files from the same ip at the same time. If the server allows you to
download more than two files at the same time it's even a bad thing because
you loose out. Server side queuing makes sure people get the download they
requested in the order the downloads were requested. It's an extremely good
thing. If you don't have server side queues you have polling.

Hotline used to have a system where there was no queue on the server. Now
they have a queue on the server. They also have a queue on the client to
make sure that a client doesn't download two files at the same time. These
two are separate things with separate goals..

Any arguments about the fairness of polling are ridiculous.

On 1/10/03 9:46 AM, "heavy baby" <hea...@ya...> wrote:

>> under MacOS X as well?
> it happen under MacOS Classic only.
> so Apple MRJ might have a bug around network...

Classic MRJ is totally terrible. I would be surprised if any one can use
Myter as a server under MacOS 9 fore more than a few hours. I mean the thing
is 1.1 compliant only. It uses a 1.1 VM! It has memory leaks like crazy! It
has co-operative multitasking! ARGH!

At least under MacOS 10 we have a system that can be a server for weeks
without crashing. Although the awt GUI widgets are flaky. That double click
causes two download bug + the crash on download bug are evidence of that..
they are also incredibly slow. Adding elements to java.awt.List is mind
blowingly slow. Hopefully they can fix the remaining bugs in the 1.4.1 VM.
Then we can see Myster as it was meant to be!

> Too many changes badly thought out.
yes. it's too hard. cheer up.

> its due to be replaced completely with multi-source download.
great thing! it makes us happier.

> It might happen if the person who is trying to download is overloaded.
> Otherwise I can't see how it would happen.
ah, ok. if i can see this situation in debug mode, i'll send you the log.
with something explanation.

> Kick freeloaders only kicks those servers which are not reachable.
wow, i understood. it was one of my wish too.

cheers,
heavy baby

__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!
http://bb.yahoo.co.jp/

hi,

> under MacOS X as well?
it happen under MacOS Classic only.
so Apple MRJ might have a bug around network...

thanks,
heavy baby

__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!
http://bb.yahoo.co.jp/

On 1/10/03 12:34 AM, "heavy baby" <hea...@ya...> wrote:

>> I intend to have the server queue all downloads but not allow one person
>> to download or be queued for more than one file at a time. The server will
>> disconnect any users who try to download (or queue) more than one file
>> at a time.
> I have tested latest CVS build, but it dosen't work.
> I get 4 queue from one user.

I haven't done anything yet. I'm still working on chat, messaging and
throttling.

Changing queuing is a bit involved because FileDownloaderThread is messy.
Too many changes badly thought out. It makes adding client side queuing a
major affair. I haven't fixed it because its due to be replaced completely
with multi-source download.

> And Kick freeloaders option dosen't work correctly.
> sometimes it kicks the user non-freeloaders ( who share some files).

This isn't supposed to happen. It might happen if the person who is trying
to download is overloaded. Otherwise I can't see how it would happen.

> sometimes it dosen't kicks freeloaders ( who are sharing 0 file ).

Kick freeloaders only kicks those servers which are not reachable. It
doesn't look at the number of files stats as the number of files stats could
be forged.

On 1/9/03 11:35 PM, "heavy baby" <hea...@ya...> wrote:

>> I will then make the clients queue up there download automatically
>> if they make multiple request to one server.
> it's good. and this mean client side queue.
> and also i think if the server download spot are fulled,
> the client queue should be disconnected,
> and ther server should be returned "busy" message or something else
> to the client.
> so client will try requeue automatically in any interval.
> 
>> It freezes when many people are queued?
> yes. it is true.

under MacOS X as well?

>> Are you talking abut myster's annoying tendency to hang-up on people
>> if there are more than 10 people queued or something else?
> no, I'm talking about client side queue system.
> if client queue are supported, interval or something method are needed.

ok

i have one mistaked
                       
".exe",".zip",".gz",".tar",".z",".rmj",".lqt",".iso",".cue",
                       
".iso",".ccd",".rar",".ace",".cdr",".gzip",".lzh",".lha"
".iso" are dubbled, sorry.

hv

__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!
http://bb.yahoo.co.jp/

Hi.

> I intend to have the server queue all downloads but not allow one person
> to download or be queued for more than one file at a time. The server will
> disconnect any users who try to download (or queue) more than one file
> at a time.
I have tested latest CVS build, but it dosen't work.
I get 4 queue from one user.

And Kick freeloaders option dosen't work correctly.
sometimes it kicks the user non-freeloaders ( who share some files).
sometimes it dosen't kicks freeloaders ( who are sharing 0 file ).

cheers,
heavy baby

__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!
http://bb.yahoo.co.jp/

i'm afraid of server side queue.
if server side queue are supported...
    the people A who has many files will get grows grows.
    the people B who has poor files will not get grows.
    gulf of wealth and poverty probably will be widens.
    because A will never let upload to B.
   you see this dirty situation in WinMX most popular in japan.
   WinMX uses server side queue!

if client side queue are supported...
   everyone will get chance to download!
   everyone will be equality!
   and Myster will be true filesharing client.
   this is freedom that i believe.

thanks,
heavy baby

__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!
http://bb.yahoo.co.jp/

> I will then make the clients queue up there download automatically
> if they make multiple request to one server.
it's good. and this mean client side queue.
and also i think if the server download spot are fulled,
the client queue should be disconnected,
and ther server should be returned "busy" message or something else
to the client.
so client will try requeue automatically in any interval.

> It freezes when many people are queued?
yes. it is true.

> Are you talking abut myster's annoying tendency to hang-up on people
> if there are more than 10 people queued or something else?
no, I'm talking about client side queue system.
if client queue are supported, interval or something method are needed.

cheers,
heavy baby


__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!
http://bb.yahoo.co.jp/

I thought I would write to everyone here and talk about the status of Myster
Chat. Myster chat is basically done. The preference pane work. The chat
works. The private messaging works. Individual message forums are there yet
but there in the protocol so we're ok. The only thing stopping me is the
beep command.

right now the way Myster chat works is each chat client send commands to the
server. Each command is an entry is the root of a MML structure sent as a UT
String. There are three types of commands (curently)

server -> client
client -> server and
client <-> client

client client commands are actually a client server command called forward.
Forward has a parameter which is an MML blob which in turn contains commands
to a client. 

<Forward><To>2</To><From>1</From><Msg>MML Structure to send to the client as
data</Msg></Forward>

Ok, so this works great. The only problems occur with results.

Lets' say I wanted to send some sort of query to a remote client.. That is a
command that returned a result. Right now, I can't. I though about making a
/result parameter.. That would work though be messy

outgoing ->

<Some command><arg1>...</arg1><arg2>...</arg2></Some Command>

incommging ->
<Some command><Result>result</Result><Some Command>


There's also an additional problem of sending nulls with MMLs.. You can't do
it.

That is, in a regular procedure/function in a program, you know you got a
result or not because your program returns, that is the program flow
continues. With the protocol above this doesn't exist so you're never sure
if/when a command was executed and if it was understood. No only that but
you know you've sent a null if the pointer (or reference) is 0. MML is a bit
too low level for that. There's no defined value for null. The value 0 is
ok.

I'm tempted to send commands as

UTF -> command name
byte -> type (return (void result), error, result)
UTF -> MML with the parameters, error info or result

The following tags would be reserved in MML:

"error", "command id" (for added robustness and error detection).. others??

Blurgh..

comments?

On 1/9/03 1:18 PM, "heavy baby" <hea...@ya...> wrote:

> my opinions are not only mine, client side queue & one upload per user is our
> answer.

I intend to have the server queue all downloads but not allow one person to
download or be queued for more than one file at a time. The server will
disconnect any users who try to download (or queue) more than one file at a
time. I will then make the clients queue up there download automatically if
they make multiple request to one server.

> because when i get many queue from others,
> myster gets heavy thread and sometimes freezedowns.

It freezes when many people are queued? I've never had that problem. What
exactly do you mean?

> if the server returns two-digit or three-digit, the user will be be
> disheartened.
> we don't see "queued" number. we want to see "retrying at ***sec" in interval.

What are you talking about? Are you talking abut myster's annoying tendency
to hang-up on people if there are more than 10 people queued or something
else?

> i see many japanese users who want to share equality and to get light thread.

On 1/9/03 12:35 PM, "425...@sn..."
<425...@sn...> wrote:

> On Fri, Jan 10, 2003 at 12:45:18AM +0900, heavy baby heavy_baby-at-yahoo.co.jp
> |sourceforge/1.0-Allow| wrote:
>>> Could anyone fill me in to why there's a spike in the stats these last few
>> days?
>> 
>> i have added more filename extensions to FileFilter.java.
>> i'm sorry for my lack of explanation...
> 
> Make sure you inform Trumper when making changes to the
> code. He his the only one that can tell you how your ideas
> fit into the grand scheme of things for Myster.

Firing off questions here is the best way of going about it a change. It is
slower now but it avoids problems, incompatibilities, getting locked into a
bad idea, bugs, framework issues, bloat code and other nasty surprises
later. I am glad, when I wrote the FileManager and Tracker etc.. code, I
wrote it such that the design has no problems with adding/removing types.

(Although I must admit to being unhappy that I need to change not only the
typeDescription list but also the FileFilter.java.. ideally the
FileDescriptionList.txt should be an (internal) config file for
adding/removing/configuring generic file based myster types (type,
description, allowed file extension, maybe some sort of language for
expressing meta data too.. although that's a pipe dream..). Anyway, that's a
feature for another day.)

(At least we're not the linux kernal, yet, so there's still stuff we can get
away with. Like I have most of the code in my head, so when stuff goes wrong
I generally know where. I wonder how long that will last :-)   )..

> Remember the discussion about kicking leeches - it's really
> important that you talk to him! Preferably before you commit
> to the cvs, even!
> 
> Maybe you can adopt the Linus' model. People in general do
> not change the Linux kernel code, they send patches to Linus
> Tovalds, who then evaluates then in the context of the rest
> of the design. You can make a patch using the command line :
> 
> diff -ru myster-old myster-new > myster.patch
>  
> Then mail the myster.patch file to Trumper.

This is as much of an annoyance for me as it is for the people submitting
code patches. I would like to avoid bureaucracy until it becomes necessary.
Since we are only three, it should be possible to do this without needing a
gatekeeper. All we need is a bit of self discipline and communication when
it comes to changes and discussing new features before implementing them.
CVS (and the awesome CVS history kept at sf.net) should allow for easy
regressions when mistakes are made.

> Also, you said the Makefile didn't work, yet still haven't
> mention anything about how it breaks.
>
> I can't help you if
> you don't tell me what's going wrong, you know. You might
> want to read :
> 
> http://www.mozilla.org/quality/bug-writing-guidelines.html
> 
> It's for mozilla, so it makes it rather overkill for our
> purpose. It is still good advice and a perfectly good source
> of inspiration.

good advice in any case.

Mmm I want some lunch...

>   diff -ru myster-old myster-new > myster.patch
> Then mail the myster.patch file to Trumper.
first, i'm very sorry about my doing.
i really understand what to do.
i'll stop using cvs and start making the patch.

this is the error message,
directory method or something might be incompatible...

bash-2.05a$ make
mkdir -p classes
for f in ./com/myster/server/stream/firewall.gif
./com/myster/server/stream/queued.gif ./com/general/tab/tab_background.jpg
./com/general/tab/left.gif ./com/general/tab/graphs.gif
./com/general/tab/middle.gif ./com/general/tab/outbound.gif
./com/general/tab/right.gif ./com/general/tab/serverstats.gif
./typedescriptionlist.txt ./mysterprefs.mml ./com/properties/Myster.properties
./com/properties/Myster_ja.properties lib lib/collections.jar
lib/hellikerID3v2.jar; ?
        do mkdir -p classes/`dirname $f`; ?
           cp $f classes/$f; ?
done
cp: ./mysterprefs.mml: No such file or directory
cp: lib is a directory (not copied).
export CLASSPATH=classes:lib:lib/collections.jar:lib/hellikerID3v2.jar:; javac
 -d classes ./Myster.java
./Myster.java:16: cannot resolve symbol
symbol  : class MysterThread  
location: package util
import com.myster.util.MysterThread;
                       ^
.
.
.
44 errors
make: *** [classes/./Myster.class] Error 1

especially queuing issue is very important for us.
what do you think about it?
my opinions are not only mine, client side queue & one upload per user is our
answer.

because when i get many queue from others,
myster gets heavy thread and sometimes freezedowns.
if the server returns two-digit or three-digit, the user will be be
disheartened.
we don't see "queued" number. we want to see "retrying at ***sec" in interval.
i see many japanese users who want to share equality and to get light thread.

cheers,
heavy baby

__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!
http://bb.yahoo.co.jp/