Re: [Loco-dev] loco: questions & comments

[Janico Greifenberg]

On Wed, May 22, 2002 at 06:25:25AM +0200, . wrote:
> 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)

What makes you think that? The options are parsed by POpt which is a commonly
used lib for option parsing.
 
> - 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.

This was a problem with the number of chars read, but it was fixed by Arne who
is now working on loco-msg.

> - 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)

The problem with the used ports has to do with the threads: there is a thread
listening contantly for incoming tcp/ip connections. When the application exits
that thread is simply killed so it has no chance to close the socket and the
port is used until the system takes care of that.

> just remembering about some "ReUse" flag perl IO::Socket knows; anything
> similar here?

I just consulted my big book of network wisdom and there is indeed a socket
option for the reuse of server sockets. I will implement that.
 
> 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 :-(

The idea is that the proxy accepts all the connections for its client and
saves the data; the client connects to the proxy and retrieves the data. The
reason for this is that the proxy doesn't need a way to connect to the client
either so any peer can be your proxy. Of course it sould be possible to specify
your dedicated proxy which is for example your router for better performance. If
you use the first way there should be more than one proxy so whenever a
connection to the client is requested one of its proxies is randomly chosen for
load balancing reasons. This will require a change in the peer structure as
there must be one or more addresses for any peer but that's quit easy.
 
> 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).

That's a good idea, though I prefer using GLists for safety reasons.
 
> concerning data/files transfer:
> is there a special reason not to use c++?

Yes, I wanted to make it as easy as possible to include libloco in any kind of
program and C is the standart language for libraries. 

> though LocoData doesn't look like a good base to derive from anyway,
> looking through binary stuff to remove string terminators...

We might need to go though that code to enable binary data, but that shouldn't
be too difficult.

> 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?)
I know it's used in other free software (example: cons) so this should be OK but
we sould research the licensing issues nevertheless.
>       - 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)

Actually signatures are a superset of checksums so if performance allows signing
we don't need extra checksums, otherwise your suggestions seem pretty useful.
 
> <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>

By Thor, the God of Thunder. The God of Rain. The God of the
High  Towering Clouds.  The  God of Lightning. The  God  of  the Flowing
Currents.  The God of  the  Particles.  The  God of the  Shaping and the
Binding Forces. The God  of the  Wind. The God of the Growing Crops. The
God of the Hammer Mjollnir.
This error message style is just a joke, but we can fix that if it's so
important for you.

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

So long
   Divo
-- 
Warning! Taking anyone (especially yourself) too serious will be harmful

binSmPd6qBT_u.bin
Description: PGP Key 0xFE95380C.

pgppoboZ7dlYu.pgp
Description: PGP signature