gnunet-developers
[Top][All Lists]
Advanced

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

Re: [GNUnet-developers] GNUnet and chat ?


From: Christian Schulte
Subject: Re: [GNUnet-developers] GNUnet and chat ?
Date: Sat, 10 Apr 2004 14:02:55 +0900

On Fri, 9 Apr 2004 13:59:24 -0500
Christian Grothoff <address@hidden> wrote:

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

Within GNUnet i would not like to see dedicated servers if they can become of
interest for bored kiddies. Those main points of infrastructure could become 
easy
targets of attacks. 
But when you mention hashes. I remember that we have (32 bit ?) hashes to 
identify data
blocks within AFS. Is the possibility really that small that we get the same 
hash
for 2 different data-blocks some day ? Lets say after inserting a few 100 
Terabyte.
Or would the amount of data need to be that much bigger to make it realy
unlikely to happen? I just wondered about that recently.



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

Yes i saw that. I just meant nodes that are in the path of message routing.
But thats an inevitable thing. A node can drop without further notice.
And other nodes which have been relaying data to it will suddenly need to choose
an alternate path (maybe even based on old data until they receive the next 
broadcast).
This could lead to some loss. But we cant really help it if the structure 
really fails
like this.


  Chris




reply via email to

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