<div class="gmail_quote">2011/10/18 Matthias ¦ubik <span dir="ltr"><<a href="mailto:funke@matthias.subik.de">funke@matthias.subik.de</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hallo,<br>
<div class="im">On 18.10.2011, at 07:50, <a href="mailto:kaefert@gmail.com">kaefert@gmail.com</a> wrote:<br>
<br>
> 2011/10/18 Markus Kittenberger <<a href="mailto:Markus.Kittenberger@gmx.at">Markus.Kittenberger@gmx.at</a>>:<br>
>><br>
>>>> Am 16.10.11 19:47, schrieb <a href="mailto:kaefert@gmail.com">kaefert@gmail.com</a>:<br>
>>>>> Auch sehr interessant (wobei das wohl eher nur Spielerei,<br>
>><br>
</div><div class="im">...<br>
>> und sowie afair der chat/plugin konzipiert wurde (alles broadcasten) würde<br>
>> er zwar funktionieren (und auch nit wirklich aufwendig zu coden sein),<br>
>> aber eben mit unschön viel overhead produzieren #1 und trotzdem nit wirklich<br>
>> verlässlich arbeiten,..<br>
><br>
><br>
</div>...<br>
<div class="im">> Um brauchbares Chatten zu<br>
> implementieren müssten sich die Clients gegenseitig kennen und sich<br>
> entweder per TCP Nachrichten schicken oder falls das nicht gewollt ist<br>
> eben auf Applikationsebene einen Acknowledgment-Mechanismus aufbauen.<br>
</div>ähhhh,<br>
man muss ja nicht gleich TCP in UDP oder gleich IP nachbauen,<br></blockquote><div>jein, man könnte (wenneinem fad wäre) sich schon was effizenteres überlegen,..</div><div>(effizienter für die annahme das viele leute in einem mesh chatten, und endtoend acks wirklich nicht notwendig wären) </div>
<div><br></div><div>evt. wird olsrd eh mal irgendwann selber acks/retransmits in seinem flooding haben,..</div><div><br></div><div>dann könnte man immerhin verlässlicher (allerdings mit etwas latenz und weiterhin mit grossen overhead) darüber chatten</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
><br>
...<br>
<div class="im">> Wobei vermutlich der einfache Weg<br>
> diesen Vorteil zu erhalten wäre einen vorgefertigten bereits<br>
> existierenden Network Messenger zu verwenden, der nur die gegenseitige<br>
> Registrierung über Broadcasts macht, und die echte<br>
> Nachrichtenzustellung über direkte Kommunikation per TCP Pakete an<br>
> alle Teilnehmer regelt.<br>
</div>IMHO würde es ganz gut kommen, wenn wir da ein wenig mehr "Marktanalyse" machen könnten, bevor wir über Um- und Zubauten reden.<br></blockquote><div>ACK!</div><div><br></div><div>und imho würds keiner verwenden, sowie den irc channel (der ja immerhin exisitert und verlässlich funktioneren würde) ja auch nit,.. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
>> insofern wirklich traurig dass es das plugin nit gibt, bin ich zumindest<br>
>> keineswegs,...<br>
>> lg Markus<br>
>> #1 ein zeile chat würde da glatt soviel traffic im netz machen wie eine<br>
>> sekunde youtube schauen *GG<br>
><br>
> Also dass Statement möcht ich wirklich mal bezweifeln. Kannst du mir<br>
> begründen wie du auf das gekommen bist? Ich mein eventuell von der<br>
> Gesamt-Anzahl der Packete, aber sicher nicht von der Datenmenge.<br>
<br>
</div>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</blockquote><div>hmm sinds wirklich schon 5? (-;</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> (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.<br>
</blockquote><div>jein, (zumindest das bmf plugin), flooded afair auch immer alle multicasts nach ueberall,.. </div><div>(aber evt sind andere plugins oder auch bmf inzwischen intelligenter)</div><div><br></div><div>nachteil der multicast plugins, die müsste "jeder" node instaliert haben,.</div>
<div><br></div><div>darum kam es afaic ja zu der idee, das normale olsrd flooding, für den message transport zu verwenden,..</div><div>(dann brauchen nur die chat user, ein chat plugin)</div><div><br></div><div>imho taugt das aber bestenfalls für "zentrale" statusmeldungen, z.b. bei fastkomplettausfällen,.</div>
<div><br></div><div>die dann auf jeder router-statusseite (also <a href="http://192.168.1.1">http://192.168.1.1</a> für die meisten user) angezeigt werden könnten</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Ich darf hier die Rechnung für ihn nachliefern (wenn ich es richtig verstanden habe):<br>
<pseudocode> DataSent = MessageSize*LinksImMesh </pseudocode><br></blockquote><div>jep das ist der worst case,.</div><div><br></div><div>olsrd ist etwas besser (ohne funktionerendes MPR aber eben nit viel besser,..)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.<br></blockquote><div>ACK </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
my two cents …<br>
Matthias<br>
<br>
<br>
---<br>
A: Yes.<br>
> Q: Are you sure?<br>
>> A: Because it reverses the logical flow of conversation.<br>
>>> Q: Why is top posting annoying in email?<br>
<div><div></div><div class="h5"><br>
<br>
<br>
<br>
--<br>
Wien mailing list<br>
<a href="mailto:Wien@lists.funkfeuer.at">Wien@lists.funkfeuer.at</a><br>
<a href="https://lists.funkfeuer.at/mailman/listinfo/wien" target="_blank">https://lists.funkfeuer.at/mailman/listinfo/wien</a><br>
</div></div></blockquote></div><br>