loco-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Loco-dev] loco: questions & comments


From: .
Subject: [Loco-dev] loco: questions & comments
Date: 22 May 2002 06:25:25 +0200

hi loco developers,

browsed through (most) of the source tonight, this is what i
though/think:

- loco-msg seems sensitive to the order of params, though i can't
reconstruct that order (for now)

- sending msgs to somebody using the email as key fails when trying
loco-msg>msg address@hidden
(imho @ is treated as special character) while just typing msg and than
entering an email works.

- got lots of errors imho caused by trying to access already used ports
so q: connections (unless kept alive, by the way: do you do that?) get
closed after some time, so the ports on both ends get reuseable after
some time again, too? (don't know this exactly)
just remembering about some "ReUse" flag perl IO::Socket knows; anything
similar here?

about the proxy job: as i understand the code (and a netstat dump), each
node has one dedicated listening socket (--port). given a root and a
client node, there is a conn between the clients contact port and a
(randomly chosen) high port. so i guess:
client>new_conn(from=local:--port, to root), root creates conn with one
of the preforked tasks (to contact port of node) and closes conn on its
contact port?
so a node only need to listen on one port?
that should be easy to do for anyone with the ability to forward a
single port from her/his reachable box, filter through a socks proxy and
i think i can make up something loco-internal.
though load-balancing & splitted_file transfer optimization will imho
require a lot of knowledge on the tree structure :-(


about plurals and loco_key_find_*
that's it. zero is ok, one too. but you'll never see two ;-)
though the corba specs have a similar problem. i suggest always
returning a pointer to an array of matching info(s).


concerning data/files transfer:
is there a special reason not to use c++?
though LocoData doesn't look like a good base to derive from anyway,
looking through binary stuff to remove string terminators...

i'd like to work on file transfer asap, any problems/comments about:
        - using other GPL source
        - using MD5 algo (though NOT really free, better ideas?)
        - an new field for LocoData: char* data_checksum
        - basic idea (stolen from edonkey): one total checksum +        
filename +
size == unique id, calc checksum for each segment       (while transfering)

<rant>
Divo, by all gods you hold dear, could you please, not use german
special chars (in error msgs.)?
kinda makes me aggressive, when i have to strace/gdb to read the
complete error description...
thanks
</rant>

feedback appreciated (yo A.B. - anyone alive over there?, can you resend
gpg keys?... /home was lost in hd crash)

best regards,
tok




reply via email to

[Prev in Thread] Current Thread [Next in Thread]