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

[Arne Brix]

On Wed, May 22, 2002 at 09:31:40AM +0200, Janico Greifenberg wrote:
> 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.
Indeed, and my new functionality now 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)
> 
> 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.
Maybe it would be better to keep an open socket from "client" to
proxy, to avoid polling, wich i consider harmfull.

> > 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.
I would not like any source included, that is juristicaly unsafe, even
if other projects do so. No objections to gpled code as long as it is
well documented and bears no other license problems, but ofcause divo
has the final word on this.
Btw. i like the signing idea.

> > <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.
note to tok: see divos sig... 
> > 
> > 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
cu
   weasel
Content-Description: PGP Key 0xFE95380C.
> pub  1024D/FE95380C 2002-02-03 Janico Greifenberg (divo) <address@hidden>
> sub  1024g/F328140E 2002-02-03

pgpIj8jTzgd7H.pgp
Description: PGP signature