[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUnet-developers] GNUnet and chat ?
Re: [GNUnet-developers] GNUnet and chat ?
Sat, 10 Apr 2004 02:12:16 +0900
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.
>> If i understand the GNUnet layer
>> right there is no guaranty to get my packages through to everyone. But a
>> protocoll for chat i think forbids something like a response or retransmitt
>> for economic reasons.
> I disagree. You can have confirmations (especially if they are short,
> confirm multiple messages and are routed efficiently).
Of course i can send them myself and "route them efficiently" but i dont want
to spend that much coding effort on that at this stage. It could still be added
Also in a chatsystem one confirmation would potentially not confirm multiple
messages because those confirmations would need to go back to all the different
of their origin thus going all to different neighbouring nodes.
>> It might be a bit difficult to provide a chat system
>> at a low bandwidth cost. Or is there a way to get the packages through
>> whatever it costs if they can wait long enough. (like 5 seconds or so)
> Chat should not require much bandwidth to start with (who types that fast?).
> The latency is a more important question, and that probably depends more on
> if you want to hack up an anonymous chat or an ordinary chat. In principle,
> both should be possible on top of GNUnet.
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)
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 ?
I remember that knapsack solving in GNUnet ... is this the point of its use ?
>> 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.
> The distinction between nodes that support the chat protocol and nodes that
> don't is then only to be made in the first stage where the chat room is
> formed (sign-on, find open rooms, etc.). And there, peers that don't support
> the chat protocol should just be treated as peers that are
> 'unreliable' (since a good implementation should never assume that any other
> peer actually does what they claim to do). Sending a bit more traffic to
> peers that don't understand it this way should not be a problem since this is
> just done when the protocol is initiated and not for the actual bulk of the
You mean broadcasting during initialization and routing later (based on the
information from the broadcasts). Sounds like a good idea.
> At least that's my 2 cents.
2 cents ? :)
Thanks for your extensive comment Christian !
And sorry to bother you with more of this :)