asio asynchron synchron

[alterbro]

es geht eigentlich nur darum etwas bestätigt zu haben

asynchrone operationen haben den vorteil, dass man nur auf einen einzigen aufruf auf rückgabe warten muss, ausserdem ist es komplizierter.

bei der klassischen synchronen verwendung alles direkt beim aufruf ausgeführt, dafür muss bei jedem aufruf gweartet werden, was Fehler rückmeldungen erschwert.

sonst unterscheideiden sie sich nicht, und die wahl des verfahrens hat lediglich Programmkosmetische gründe und beide funktionieren gleich.
asio ist also nicht speziel auf eine weise ausgelegt, und die meisten anderen netzwerk libs funktionieren synchron.

ich hoff ich nerv hier nicht wieder mit meiner unerfahren heit, aber es wäre nett wenn ich das nun endlich geklärt haben könnte

[314159265358979]

Asynchrone Operationen lassen sich sauber abbrechen.

[alterbro]

wenn das der einzige fehler ist, hab ich mich gread dazu entschlossen zu synchronen abläufen überzuwechseln, die asynchronen machen mich verrückt

danke

[314159265358979]

Es ist nicht der einzige Grund, aber für mich der wichtigste. Alle meine Anwendungen, die Sockets verwenden, müssen auf Befehl herunterfahrbar sein.

Ein weitere Grund, der für asynchrone Operationen spricht, ist, dass man damit weit mehr Benutzer handlen kann, da mehrere Benutzer / Thread möglich sind.

[alterbro]

aber bei synchronen operationen können sich doch trozdem mehrere clients verbindenen oder was meinst du damit?

[314159265358979]

Bei synchronen Operationen kannst du genau 1 Client / Thread haben. Deine maximale Anzahl an Clients ist damit die maximale Anzahl an Threads, die dir dein OS geben will. Mit Asynchronen Operationen liegt die Grenze bei der Hardware.

[alterbro]

dann ncoh eine frage:pro client braucht man also einen thread und ein socket.
und bei synchronen operationen müsste man sich also jedes mal neu mit dem client verbinden?

[Ethon]

Du verstehst das Konzeot nicht so ganz.
Synchron: Du startest eine Operation und wartest bis sie fertig ist.
Asynchron: Du startest ein Operation und kannst sofort weitermachen. Sobald die Operation fertig ist, wird ein Callback aufgerufem um dir das Ergebnis mitzuteilen.

Ansonsten gibt es keine Unterschiede.

[alterbro]

mit dieser aussage wiedersprichst du eigentlich pi, aber stimmts nun dass mit synchronen operationen nur ein client möglich ist?

[Ethon]

alterbro schrieb:

mit dieser aussage wiedersprichst du eigentlich pi, aber stimmts nun dass mit synchronen operationen nur ein client möglich ist?

Nein, du kannst mehrere Clients auch synchron haben. Es kann aber sehr holprig sein diese zu bedienen.
Mit select oä. müsstest du herausfinden welche Clients überhaupt etwas gesendet haben bevor du zum Lesen anfängst. Dann hast du noch den Nachteil dass das Lesen/Schreiben genauso langsam ist wie deine Netzwerkschnittstelle. Dh. wenn du einem Client viel sendest, werden andere Clients lange Zeit überhaupt nicht behandelt, da send erst zurückkehrt sobald auch das letzte Byte angekommen ist.

Bei asynchronen Operationen kümmert sich das Betriebssystem darum, was wie auf die Leitung geht.

[314159265358979]

select ist doch asynchron...

[Ethon]

314159265358979 schrieb:

select ist doch asynchron...

select ist synchron. Du hast einfach nur den Vorteil nicht zu blockieren bevor überhaupt irgendetwas passiert ist. Der Rest läuft komplett synchron ab.

[314159265358979]

Also nach meiner Definition: blockierend = synchron, nicht blockierend = asynchron

[alterbro]

ok, also sollte ich doch bei asynchronen operationen bleiben.

Es hat mich halt einfach genervt wie die biespiele in der doc dermassen verwirrend kompliziert in eine klasse geflochten wurden, aber ok, danke

[einfach nur lol]

314159265358979 schrieb:

select ist doch asynchron...

Sei doch einfach leise wenn du keine Ahnung hast.

[Ethon]

314159265358979 schrieb:

Also nach meiner Definition: blockierend = synchron, nicht blockierend = asynchron

Die Linux-manpages bezeichnen select auch als synchron.

select, pselect, FD_CLR, FD_ISSET, FD_SET, FD_ZERO - synchronous I/O
multiplexing

Außerdem blockiert man mit select ja auch, einfach nur nicht häufiger als nötig.

[314159265358979]

einfach nur lol schrieb:

Sei doch einfach leise wenn du keine Ahnung hast.

Verzieh dich, unwerteres Lebewesen.

[hustbaer]

@314159265358979
Asynchron und non-blocking sind nicht das selbe.

Non-Blocking heisst nur, dass man so arbeiten kann, dass nie ein Befehl (unerwünschterweise) blockiert.

Die Operationen (accept/recv/send/...) erfolgen aber immer noch "unmittelbar" (d.h. es ist alles nach dem Aufruf von accept/recv/send/... abgeschlossen), oder eben gar nicht (EWOULDBLOCK). Man braucht daher z.B. auch keine Puffer, die länger als ein recv/send/... Aufruf gültig sind (d.h. man kann z.B. auch mit Stack-Puffern arbeiten).

Asynchron dagegen bedeutet, dass man mit dem Funktionsaufruf (wie auch immer der dann heisst) nur sagt: fang jetzt an mit accept/recv/send/..., und sag mir wenn du fertig bist. D.h. man muss Puffer an das IO System übergeben, und garantieren dass diese so lange gültig bleiben, bis das IO System den Aufruf abgeschlossen hat.

Wichtiger Unterschied.

Was das Abbrechen angeht: das ist mit non-blocking IO am allereinfachsten, da man keine asynchronen Aufrufe canceln muss.

[PIstroyer]

Jetzt regt er sich wahrscheinlich auf, weil du ihn belehrt hast.

[314159265358979]

Nein, nur über Vollspastis wie dich. Und nun verkriech wieder in das Loch, aus dem du hergekommen bist.