Re: [GNUnet-developers] GNUnet and chat ?

[Christian Grothoff]

On Friday 09 April 2004 12:12 pm, Christian wrote:
> I thought having a minimum level of anonymity in that chat cant hurt.
> Though a system like AFS would make chatting rather difficult due to the
> timing. I also thought about the great difference to common chat systems
> where there is some kind of server allways. I suppose on GNUnet even a
> chat-system doenst want to have servers. That brings some problems to the
> idea of confirming messages. Since everybody needs confirm to everybody, it
> would require a great deal of effort on each client to track those confirms
> for routing efficiently.

Well, there is having one fixed server and electing a peer to coordinate (say, 
per chat-room).  I wrote the GNUnet-DHT group earlier this year that a chat 
could use a DHT where essentially the name of the chat-group determines the 
peer responsible for the relaying (using DHT-put/get operations for chat).

> Of course the input alone would not be the problem. The bandwidth issue is
> more about the high unreliability of the lower layer which would (during
> high load) drop enough packages to make many retransmissions necessary
> which then make the client-to-client latency unacceptably high.
> If i can send really small packages (like 20 bytes for a "Hello" message)
> without having them padded by the core layer it might be less an issue.
> But the core layer does padding up to the MTU automatically, doesnt it ?
> Or can small packages become padding-data for bigger ones of
> another protocoll type (i.e. AFS) ? And is that likely to hapen ?

Yes and yes.  GNUnet groups all kinds of messages together using a knapsack 
solver.  So tiny ACKs are likely to be completely free.  

> I remember that knapsack solving in GNUnet ... is this the point of its use
> ?

Exactly (and that's also where most of the CPU load comes from).

> >> Another point is: Does the GNUnet layer allready communicate with other
> >> nodes what kinds of data they can process. If an old Node can not do
> >> anything with chat-data why should we send it there. At least if it does
> >> not WANT to have the data (i.e. for bandwidth reasons).
> >
> > Actually, it's less about old nodes vs. new nodes or supporting
> > chat-protocol vs. not supporting chat protocol.  The actual messages
> > should, as much as possible, only be relayed to the members of the
> > particular chat room (and not broadcasted as it's done by the current
> > code).
>
> Yes, if i imagine some kind of announcement from time to time
> (like "i am in channels #2 #44 #423" maybe bundled with other info)
> then other hosts could relay traffic based on that information and
> it might not even cost too much computing.
> The only weak point of it would be that it causes more packet-loss
> when nodes are leaving. Maybe a middle way between strict routing and
> broadcasting could be used.

If a node is leaving, you can send a 'leave' message.  Of course, that message 
can be lost and things should still work (i.e. the node is removed after some 
time because the periodic announcements stop), but that prevents the problem 
of sending traffic to nodes that just left in most cases.  That's also how 
basically the GNUnet key exchange on the lower level works (initiate, 
periodic keepalive, shutdown, timeout).

C