Re: [GNUnet-developers] Chat System, again

[Christian Grothoff]

On Sunday 03 October 2004 16:19, Arne Wichmann wrote:
> > > One peer responsible for routing is what i proposed above and am not
> > > very happy with.
> >
> > How about a pool of peers?
>
> Why not have everyone in a channel know where to send to?

Depends on where you want to scale -- sending 1000 messages to 1000 
participants might not be such a great idea.  But then again, 1000 might be 
the upper end for chat systems anyway, so I don't have any serious objections 
to that.

> > > What is the question about delays?
> >
> > Oh, I was just wondering about latency again.  There is end-to-end
> > latency and then there are per-hop delays that peers introduce to be able
> > to do better message scheduling. In practice, you can clearly pick the
> > per-hop delay, but a certain end-to-end latency is what you want to
> > achieve.
>
> What latencies would be to be expected in gnunet?

Highly depends.  The peers do the following.  Everyone has a bandwidth limit.  
If you want to send a message batch of 1500 bytes, that gives you K messages 
total for sending per second (say).  If you want to send every peer a message 
at least every N seconds, you try to establish approximately K*N connections.

Now, K depends on the local configuration and 'N' is somewhere in connection.c 
(with some more tuning parameters).  The (current) result is something like a 
message every few seconds on average.  Now, if the chat messages have enough 
of a priority they would always get into the next batch.  For end-to-end 
latencies, multiply N by number of hops.  

Other than that, you get effectively the latency of TCP on the specific 
connection.

> > Maybe an expire feature would be useful for afs, too. Forwarding nodes
> > could drop expired answers (3HASH messages), and successful downloads
> > could reinsert them with updated expire time.
>
> That might help with those files of which only the 3HASH seems to be left.

Yes, and it is planned to do this (for 0.7.0, which is the number where 
compatibility will be broken).  Until then, there's no expiration in AFS.

Christian