[Wien] IRC Channel

[Markus Kittenberger]

2011/10/18 Matthias Šubik <(spam-protected)>

> Hallo,
> On 18.10.2011, at 07:50, (spam-protected) wrote:
>
> > 2011/10/18 Markus Kittenberger <(spam-protected)>:
> >>
> >>>> Am 16.10.11 19:47, schrieb (spam-protected):
> >>>>> Auch sehr interessant (wobei das wohl eher nur Spielerei,
> >>
> ...
> >> und sowie afair der chat/plugin konzipiert wurde (alles broadcasten)
> würde
> >> er zwar funktionieren (und auch nit wirklich aufwendig zu coden sein),
> >> aber eben mit unschön viel overhead produzieren #1 und trotzdem nit
> wirklich
> >> verlässlich arbeiten,..
> >
> >
> ...
> > Um brauchbares Chatten zu
> > implementieren müssten sich die Clients gegenseitig kennen und sich
> > entweder per TCP Nachrichten schicken oder falls das nicht gewollt ist
> > eben auf Applikationsebene einen Acknowledgment-Mechanismus aufbauen.
> ähhhh,
> man muss ja nicht gleich TCP in UDP oder gleich IP nachbauen,
>
jein, man könnte (wenneinem fad wäre) sich schon was effizenteres
überlegen,..
(effizienter für die annahme das viele leute in einem mesh chatten, und
endtoend acks wirklich nicht notwendig wären)

evt. wird olsrd eh mal irgendwann selber acks/retransmits in seinem flooding
haben,..

dann könnte man immerhin verlässlicher (allerdings mit etwas latenz und
weiterhin mit grossen overhead) darüber chatten

> >
> ...
> >  Wobei vermutlich der einfache Weg
> > diesen Vorteil zu erhalten wäre einen vorgefertigten bereits
> > existierenden Network Messenger zu verwenden, der nur die gegenseitige
> > Registrierung über Broadcasts macht, und die echte
> > Nachrichtenzustellung über direkte Kommunikation per TCP Pakete an
> > alle Teilnehmer regelt.
> IMHO würde es ganz gut kommen, wenn wir da ein wenig mehr "Marktanalyse"
> machen könnten, bevor wir über Um- und Zubauten reden.
>
ACK!

und imho würds keiner verwenden, sowie den irc channel (der ja immerhin
exisitert und verlässlich funktioneren würde) ja auch nit,..

>
> >> insofern wirklich traurig dass es das plugin nit gibt, bin ich zumindest
> >> keineswegs,...
> >> lg Markus
> >> #1 ein zeile chat würde da glatt soviel traffic im netz machen wie eine
> >> sekunde youtube schauen *GG
> >
> > Also dass Statement möcht ich wirklich mal bezweifeln. Kannst du mir
> > begründen wie du auf das gekommen bist? Ich mein eventuell von der
> > Gesamt-Anzahl der Packete, aber sicher nicht von der Datenmenge.
>
> Gerade das meine ich, bevor wir das ganze Netz damit fluten, wäre es doch
> viel 'gscheiter', wenn wir OBAMP oder eins der anderen fünf Multicast
> Plugins

hmm sinds wirklich schon 5?  (-;

(laut Google auf olsr multicast) im Mesh installieren, und dann einen
> Multicast Chat Client, oder besser ein Plugin für bestehende Messenger
> verwenden. Das würde die Zeit deutlich sinnvoller einsetzen, da dann auch
> Multicast Audio Chat möglich wäre, und das "Broadcastproblem" von dem Markus
> sprach lösen.
>
jein, (zumindest das bmf plugin), flooded afair auch immer alle multicasts
nach ueberall,..
(aber evt sind andere plugins oder auch bmf inzwischen intelligenter)

nachteil der multicast plugins, die müsste "jeder" node instaliert haben,.

darum kam es afaic ja zu der idee, das normale olsrd flooding, für den
message transport zu verwenden,..
(dann brauchen nur die chat user, ein chat plugin)

imho taugt das aber bestenfalls für "zentrale" statusmeldungen, z.b. bei
fastkomplettausfällen,.

die dann auf jeder router-statusseite (also http://192.168.1.1 für die
meisten user) angezeigt werden könnten


> Ich darf hier die Rechnung für ihn nachliefern (wenn ich es richtig
> verstanden habe):
> <pseudocode> DataSent = MessageSize*LinksImMesh </pseudocode>
>
jep das ist der worst case,.

olsrd ist etwas besser (ohne funktionerendes MPR aber eben nit viel
besser,..)


> Und da die Zahl der Links die der Nodes vielfach, und die in so einem Fall
> aktiven User bei weitem übersteigt, darf so eine Idee das Prädikat
> "ineffizient" tragen.
>
ACK

>
> my two cents …
> Matthias
>
>
> ---
> A: Yes.
> > Q: Are you sure?
> >> A: Because it reverses the logical flow of conversation.
> >>> Q: Why is top posting annoying in email?
>
>
>
>
> --
> Wien mailing list
> (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/wien
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/wien/attachments/20111018/c7c2afac/attachment.htm>