 Wir sind Kaste und Alpern und wir wünschen euch viel Spaß und Talk. Hallo, mein Name ist Philipp. Ich bin hier, um über Tabs zu reden, also der Transport Services API von BSD. Die ganze Arbeit, die ich heute vorstelle, ist immer noch unfertig. Es ist inzwischen eine relativ große Gruppe an Leuten, die daran arbeitet. Es ist auch ziemlich schön, wie weit wir da schon kommen. Aber wir reden hier viel über Internet-Drafts, also Vorschläge für die Journalisierung. Das ist immer so langwierig, aber wir haben inzwischen auch schon die ersten Implementierungen. Und es ist sehr ermutigend zu sehen, wie weit das schon irgendwie übernommen wird. Und die Frage ist jetzt, warum wollen wir überhaupt die Socket API ändern oder ersetzen? Also lass uns mal angucken, was daran falsch ist. Also müssen wir erst mal ganz weit zurück in die Vergangenheit gehen. Wie wir schon seht, das Originale kommt dem 4.2 BSD aus 1983. Da war ich zwei Jahre alt, als das veröffentlicht wurde. Und es ist etwas alt und schal geworden. Zu der Zeit war eine sehr starke Idee, dass alles eine Datei ist. Und damals hatten wir noch nicht mal virtuelle Datei-Systeme. Und wenn man ein Netzwerkverkehr bearbeiten will, hat man im Prinzip einfach eine Dateihandel aufgemacht und hat dann da reingeschrieben, um die Daten zu übertragen. Das wurde als Erweiterung von IPC, also der Inter-Prozess-Kommunikation, betrachtet. Statt dass man da jetzt IPC auf dem eigenen Computer macht, hat man einfach das Ganze weitergeleitet an andere Computer. Und das war im Prinzip ein Experiment. Was wir dann gesagt haben, ist, wir haben zwei verschiedene Arten von Schnittstellen. Die eine Seite sind die Nachrichtenbasierten. Die andere ist Schirmbasiert, also das Schreenbesten hinter das. Dafür haben sie damals das UDP-Protokoll implementiert. Also das unzuverlässigere weniger Overhead und das andere ist das TCP, das zuverlässigere aber mit mehr Overhead. Das war so der erste Satz an Schnittstellen, der einfach so funktioniert hat, wo man nicht noch mit Netzwerktreibern umformen musste und Dissemplerkeit schreiben musste, so dass jeder einfach relativ simpel, wo man in einer Hochsprache Netzwerkverkehr erzeugen konnte. Und das wurde damals der Standard, wenn er euch den BSD-Schnittstellen und die von Minus anschaut oder auch die von anderen Betriebssystemen, dann sehen die alle sehr ähnlich aus, wie sie damals bei BSD vorgeschlagen wurden. Die Frage ist jetzt, was müssen wir tun, um einen Socket aufzumachen. Das ist das klassische Ballspiel aus dem Unix Network Programming Volume, ein Standardbuch über Netzwerkprogrammierung von Stevens. Das ist immer noch die Referenz, wie sie das gemacht wird. Zuerst erzeugt man eine Integer-Variable, in der man den Socket, das High-Handel reinschreibt, dann muss man eine Strucht erzeugen, die für die Namensauflösung benutzt wird, die muss man ein bisschen konfigurieren, dann löst man das mit einem Funktionscall aufrufen und dann hat man am Schluss eine Linklist von Zeug, das einem erlaubt, dass man sich verbindet als Resultat der Namensauflösung. Wenn es schief geht, kriegt man ein Fehler, aber ab dann wird es schlimmer. Dann muss man iterieren über diese Liste und versuchen, kann ich mit diesem Socket mich verbinden oder nicht. Wenn es funktioniert, ist gut. Wenn nicht, dann muss ich einfach den nächsten probieren. Wenn es nicht funktioniert, dann blockt es, dann kriegt man ein Timeout und dann benutzt man den nächsten. Und das endrese Tat ist dann hoffentlich ein Socket-File-Handel, den wir dann benutzen können. Und am Schluss muss es halt freigeben. Also was ist jetzt das Problem dabei? Und ich sage jetzt nicht, ich denke jetzt nicht in der Terminologie von modernen APIs, sondern einfach mal gegeben, dass es jetzt in C programmiert ist, was ist jetzt immer noch falsch daran? Und der Grund ist, dass einfach der Internetverkehr sich geändert hat. Wir leben nicht mehr in 1983. Und was sich geändert hat, ist, dass wir sehr, sehr viel mehr Protokolle oberhalb dieses Stacks haben, deutlich mehr über TCP. Wir haben jetzt IPv4 und IPv6 Auf dem Transport-Layer haben wir SCTP, als ein zuverlässiges nachrichtenbasiertes Protokoll. Und das werden wir deutlich schneller sehen. Im Moment hat das hauptsächlich Google am Start, aber auch die anderen Contradistribution-Networks, die Akamai oder Cloudflare werden das alle benutzen, so dass das relativ stark sich verbreiten wird. Das wird am Ende des Tages wahrscheinlich TCP ersetzen. Und wahrscheinlich werden wir das einfach transparent einsetzen. Was sich noch geändert hat, ist, dass wir heutzutage Geräte haben, die mehr als ein Netzwerkverbindung gleichzeitig offen haben. Also in 83, wenn man ein Mainframe hatte, dann war man echt glücklich darüber, wenn man überhaupt eine dauerhafte Verbindung hat und sich nicht einwählen muss. Heutzutage hat jeder ein Handy, das mehr als ein Kommunikationskanal hat, also zum Beispiel das GSM-Netz und auf der anderen Seite die IP-basierten Netzwerke. Und je nach Protokoll muss man sich entscheiden, welchen Weg man denn nehmen. Und am Ende des Tages hat man auf der anderen Seite auch noch verschiedene Endpunkte. Also wenn man zum Beispiel mit irgendeinem CDN redet, also Google, Akamai, die üblichen, dann kriegt man Antworten und mehrere aus denen man auswählen kann. Und was man auch noch erwähnen sollte, ist heutzutage, sollte einfach alles verschüsselt sein. Also früher hat man einfach dem ganzen Netz mehr vertraut. Die paar hundert Leute, die damals im Netz waren in den 80ern, die kannte man alle sowieso. Heutzutage kannst du niemanden trauen im Internet und du musst einfach alles verschlussern. Und das sind alles Dinge, die damals nicht bedacht wurden, als die BSD Socket API damals entworfen wurde. Also sollten wir uns überlegen, wie wir das jetzt ändern können. Gehen wir wieder zurück zu unserem Lehrbuch als Spiel und schauen uns erstmal die Namensauflösung an. Wir wollen über mehrere Pfade gleichzeitig Namen auflösen. Und wenn wir über Continental-V-Notes reden, dann kann man nicht die gleiche API-Adresse durch alle Links nutzen. Also zum Beispiel, wenn man WLAN über es camp hat und über LTE, über T-Mobile und dann kriegt man wahrscheinlich verschiedene DNS-Resultate für die verschiedenen Verbindungen. Und man kann eventuell gar nicht die CDN-Knoten von der falschen Anbindung benutzen. Das heißt, man muss die Ergebnisse sammeln, getrennt sammeln und getrennt benutzen. Das geht mit der Socket API von BSD nicht. Also falls man das in irgendeiner Applikation oder in irgendeinem Programm machen möchte, dann muss man DNS selber schreiben. Willkommen. Und nächstes. Wenn wir die Resultate jetzt haben, die Ergebnisse, dann haben wir an der Stelle interessante Ergebnisse, also interessante Daten, die wir später benutzen könnten, um die sichere Verbindungen aufbauen. Das heißt, man muss DNS wieder selber implementieren. Nächstes. Wenn Benutzer dann das Programm benutzen, dann würden sie gerne schnelle Reaktionen haben. Wenn wir hier auf Timeline benutzen, dann würden sie gerne schnelle Reaktionen haben. Wenn wir hier auf Timeouts warten, dann wollen wir nicht 90 Sekunden jeweils warten. Wenn der User auf irgendeine Website klickt, dann möchte er, dass so sofort was passiert. Nicht erst 5 Sekunden warten, oder so, dann wird er etwas verärgert. Und die Idee, die moderne Browser heutzutage verfolgen, ist einfach mehrere Verbindungen gleichzeitig versuchen. Das ist ein Standard. Da schaut man, welcher Socke zuerst connectet wird. Und schaut wer zuerst connectet wird, dann nutzt man einfach den. Das heißt, man hat stattdessen eine Schleife um einen Select, E-Poll oder so KQ und so weiter. Oh, wer hat das schon alles gemacht? Einige. Jetzt, das wird wirklich eklig, das zu machen. Und mit so Dingen wie Quick, werden wir das gleiche für das Protokoll machen müssen. Das ist echt hässlich. Dann müssen wir als nächstes eine sichere Verbindung aufbauen, zum Beispiel SSL, was nicht Teil der SS Connection API ist. Das heißt, wir müssen das separat behandeln. Und am Schluss müssen wir die Protokolle, die wir benutzt haben, Quick wieder zurückgeben, weil der Socket verschiedene Semantik haben kann, je nachdem welches Protokoll man benutzt hat. Ich wollte nach einem Beispiel suchen, um das zu zeigen. Es gibt nichts auf Stack Overflow, es gibt kein Beispiel oder so. Das Beste, was ich gefunden habe, war in Lib Curl. Es war 1200 Zeilen Code lang. Okay. So, wie lösen wir das? Die übliche Idee, es gibt keine Möglichkeit, die SS Socket API zu ersetzen. Es wird einfach nicht funktionieren, sagen die Leute. Das haben schon viele Forscher versucht und haben es nicht geschafft. Es gibt nur einen Grund, aus dem ich hoffe, dass mein Versuch funktionieren könnte. Warum stehe ich hier? Letztes Jahr, als jemand sich beschwert hat, dass die BSD API ihr Projekt kaputt gemacht hat, hat eine Arbeitsgruppe bei der IETF gemacht, die gesagt haben, wir müssen was daran ändern. Erst war da bloß ein paar Akademiker, aber am Ende, am Ende, kam Apple dazu. Und die haben gesagt, sie wollen mit uns zusammenarbeiten und die das mit Verbindungen funktionieren und so weiter. Lass uns zusammenarbeiten und sie versuchen jetzt die neue Socket API, die Netzwerke, die wir haben, die ITF, die wir gerade bauen. Ich habe über die IETF geredet. Was zur Hölle ist die IETF und was die Tabs, Arbeitsgruppe? Die ITF kümmern sich um Standards. Das klingt ziemlich langweilig. Es gibt einfach viele Leute, die die ITF, die die ITF kümmern, so viele Leute, die über Standardisierung redet, wie man interoperieren kann zwischen Programmen. Nicht ganz. Die ITF ist ein ziemlich ungewöhnlicher Standards-Entwickler. Es ist eigentlich ein ziemlich nördiger Platz. Diese beiden Zitate hier repräsentieren das ITF so ein bisschen gut. Einst du von David Clark? Wir lehnen Könige, Präsidenten und abstimmungen ab. Wir wollen ungefähren Konsens und laufenden Code. Das ist ziemlich ungewöhnlich. Häufig ist es in Standards anders, dass der Code eher hinten ansteht und es noch nicht ganz klar ist. Ob man das tatsächlich programmieren kann. Das andere ist be-conservative in what you send and liberal in what you accept. Sei konservativ in dem, was du sendest, aber liberal in dem, was du akzeptierst. Das ist auch interessant, dass man versucht, die ITF zu kümmern. Es sind auch nicht einfach große Firmen, die irgendwelche Abstimmungsvoten haben, sondern es sind einfach Leute, die zusammensitzen und versuchen, Vorschläge zu evaluieren. Und wenn, wenn, wenn jetzt, wenn jetzt, wenn jetzt, gefragt wird, wer mag diesen Vorschlag, dann kann man ein bisschen brummen oder so. Und wenn man es besonders mag, dann kann man es besonders laut machen und dann kann man schauen, dann kann man schauen, wie, wie viel Zustimmung es ist. Und das ist tatsächlich relativ anonym, weil man nicht so genau merkt, wer jetzt da brummt. Wie ist die ITF organisiert? Es gibt verschiedene Gebiete, mit denen sie sich beschäftigt. Zum Beispiel Applications realtime, also Programme und Real-Zeit-Dinge, also Real-Zeit-Verbindungen, dann gibt es die allgemeine Gebiete, was einfach woanders, alles, was nun woanders hingehört, macht. Dann gibt es die Internet, das Internetgebiet, die sich um IPv6 oder das veraltete IP braucht. Dann gibt es Operations and Management. Hauptsächlich kümmern sich die um die besten Handhabungen von Netzwerken, Sicherheit, TLS, IPsec und dann gibt es noch das Transportgebiet, also die, die sich damit beschäftigen, wie TCP, SCCP usw. bei Funktionieren, zum Beispiel die Taps Working Group. Also die Taps Arbeitsgruppe ist hauptsächlich beschäftigt mit Transport-Services. Das hat angefangen mit Leuten, die darüber nachgedacht haben, in erstes, wie sie SCCP ausrollen können in der Breite, aber es kommen mehr und mehr Leute dazu, die darüber reden, Methoden zu finden, wie man Sockets auswählt, wie man Netzwerke mit Multiplinen zugriffen, also die Prinzip mehr Transportwege verwenden können. Die Frage ist, was wisst ihr darüber, wie der durchschnittliche Amerikaner Taps versteht? Taps ist die Melodie, die man üblicherweise spielt bei einem Soldatenbegräbnis. Das war was, wo die Amerikaner in der Arbeitsgruppe darüber gelacht haben, aber zurzeit als jetzt, wo wir anfangen, die BSD Socket API zu beerdigen, bekommt das natürlich ein bisschen in Beigeschmack. Wir wollen Entwickler dazu befähigen, andere Protokolle zu verwenden als TCP und UDP, ohne dass sie sich damit zu viel auseinandersetzen müssen. In einer idealen Welt würde man einfach wollen, dass es einfach funktioniert und dass es geht genauso wie früher, ohne dass sie groß was tun müssen. Was wir aber auch ermöglichen wollen, ist, dass sich die Transportprotokolle weiterentwickeln können, dass wir diese Evolution überhaupt möglich machen. Und dann wollen wir auch noch abstrakte APIs für die Transportservices vorschlagen. Und dann fragten wir sich natürlich, die ETF ist doch hauptsächlich mit Standardisierung beschäftigt. Wieso reden die von APIs? Und der Witz ist hier das Abstrakt. Es gibt eine relativ strikte Aufteilung in den Dingen, mit denen man sich, oder mit denen sich die ETF beschäftigt und welches sie es nicht tut. Und APIs für konkrete Programmiersprache werden in der Regel für die, wenn von deren eigenen Standardisierung Gruppen bearbeitet, als zum Beispiel die CAPI-Wit von der POSIX-Gruppe bearbeitet, die Java-API-Wit von der Java-Community bearbeitet. Und was TAPS macht ist, weil Spezifikation ist im Prinzip Input, den sie für diese anderen Standardisierung des Gremien vorgibt. Das ist mit Abstract gemeint. Das muss relativ breit sein, ein bisschen schwammig, ein bisschen generalisieren, so dass es in allen Sprachen irgendwie umsetzbar ist. Und die APIs sehen damit auch in jeder Sprache ein bisschen anders aus. Aber sie haben so hoffentlich grob ähnliche Programmier, Feeling und Konzepte, sodass wenn man von Objective C auf iOS ähnliches verhalten hat wie bei Python, nur dass es sich einmal ein bisschen mehr wie Objective C anfühlt wie Python. Aber grob ähnlich sein soll. Jetzt ist die Frage, wie schaut dieser Standardisierungsvorgang aus? Dazu muss man ein Draft schreiben. Für die Akademiker hier im Raum, das ist so etwas wie ein technologischer Report, den man schreibt. Jeder kann ihn einreichen, jeder kann ihn schreiben. Der muss durch deren Toolchain gehen, um einen schönen Eskitex zu produzieren. Aber es gibt wenig Limitierung oder wenig Beschränkungen darauf, was man damit tun kann und was man damit standardisieren möchte im Internet. Wenn jetzt die Frage wird es veröffentlicht, wenn es veröffentlicht wird, klickt das eine F10-Nummer. Wenn nicht, dann halt nicht. Und jetzt kann man versuchen, das in der Working Group zu machen. Also das heißt, man muss eine Working Group überzeugen, dass man das macht. Also zum Beispiel sagen, ich habe jetzt hier diesen Draft geschrieben und muss dann halt in die Gruppe rangehen und sagen, wollen wir vielleicht zusammen daran arbeiten und das dann zusammen einreichen. Natürlich wieder mit beiden Möglichkeiten, vielleicht wollen sie es machen, vielleicht wollen sie es auch schicken, sich auch einfach nach Hause. Und das ist das, was wir für Tabs gemacht haben. Hier gibt es auch noch einen Weg mit dem Individuen ohne Working Groupen das einreichen können. Aber das wird sehr selten noch eingesetzt heutzutage, weil so gut wie keiner mir alleine noch ein Draft schreiben kann. Wenn man jetzt soweit ist, dass man das Gefühl hat, dass man fertig, dann muss man die Angrenzen in Bereiche dazu kriegen, dass sie das einfach mal revisionen, dass sie mal drüber gucken, ob das für sie okay ist, dass sie auch eventuell davon berührt sind. Und dann muss man natürlich wieder etarieren, solange bis es hoffentlich für alle okay ist. Immer mal wieder nochmal, noch mal bis es dann soweit ist, dass alle mit zufrieden sind. Das ist irgendwo zwischen 5 und 25 Runden beim Neuschreiben, bevor wir soweit sind, dass es ein RFC wird. Wenn wir soweit sind, dass die Reviews alle durch sind, dann schicken wir es an den EASG, die Internet Engineering Standards Group, die Ingenieure des Internets, die eine sehr lauchte Runde ist, die da reingewählt wird. Die haben hoffentlich einen Überblick über ziemlich alles, was sich tut und die dann auch beurteilen können, ob das ins Gesamtbild passt und die dann auch sagen können, hey, ihr habt da irgendwas übersehen, fix das noch mal. In dem Moment, wo die es okay geben, schicken wir das an den Editor der EASG und die machen dann nur noch mal ein Review, ob noch kleine Details geändert werden müssen. Und wenn dann hoffentlich alles okay ist, dann wird es als RFC veröffentlicht. So, wenn ihr euch fragt, wo TAPS ist, dann sind wir im Moment hier, also es wurde akzeptiert als Working Group Item und kurz davor, dass wir das jetzt in die anderen angrenzenden Bereiche geben, die Reviews dazu abgeben sollen. Also wir sind relativ früh in der Pipeline. So, was ist jetzt die Idee? Wie soll das im Prinzip funktionieren? Zunächst mal ist es eine ereignisbasierte API. Im Prinzip funktionieren alle modernen Applikationen Asynchron. Man muss immer verschiedene Verbindungen betrachten, verschiedene Sockets. Man will nirgendwo mehr blocken heutzutage. TAPS hat überhaupt nichts mehr was blockiert. Ob ich jetzt irgendwie eine Verbindung aufbaue, ob ich eine Horche, ob ich lese, ob ich schreibe, alles ist ein Event. Ist es immer irgendwie ein Callback oder es kann auch eine Work-U sein, was auch immer die Frage vorsieht als Mechanismen dafür, um das abzufangen, wie wird verwendet, um das Event damit zu bearbeiten. Wenn man jetzt die Socket-API anschaut, dann ist es relativ schwierig, Informationen, immer so Hintergrundsachen, kriegt wie ICMP Request, Reject, Firewalls. Es ist schwierig, an solche Informationen anzukommen. Es soll so sein, dass wir in TAPS diese Informationen als Events auch veröffentlichen im Rahmen der API. Es soll ja die Evolution der Transportfotokolle fördern, in dem sich auf die Transport-Services fokussiert, als zum Beispiel die Anwendung soll einfach sagen, ich brauche einen Transportsocket, und dann sollte es die Anwendung auch nicht weiter interessieren, ob es jetzt ein TCP oder ein SCTP oder irgendwas anderes ist. Im Prinzip muss die Anwendung nur sagen, diese Anforderungen habe ich daran, und dann machen wir die informierte Entscheidung darüber, was der richtige Protokoll ist und der richtige Socket. Also die sollen im Prinzip die richtigen Entscheidungen treffen für das Protokoll, für die Endpunkte, für die Sockets, zum Beispiel auch so Überlegungen, wie was ist der billigste Verbindung, die wir machen können. Dann kann man diese Entscheidung auch treffen. Wenn der Link nicht funktioniert, oder wenn irgendwas anderes kaputt ist, dann nimmt man halt den... Also im Prinzip, wir haben mehrere Verbindungen zur Auswahl, der erste hat einen Vorsprung von 30 Millisekunden, wir versuchen es mit dem, wenn es funktioniert, ist super. Wenn es nicht funktioniert, dann fallen wir einfach zurück auf den zweiten und so hangeln wir uns halt durch und so kommt am Schluss einfach transparente Verbindungen zustande, die das Optimum unter den Bedingungen garantiert. Jetzt haben wir noch andere Bedingungen, also zum Beispiel wenn man Multipart verwendet und man möchte auch das schaffen, dass die Anwendung gar nicht bemerkt, dass man zum Beispiel einen zweiten TCP-Verbindung aufmacht oder und so weiter. Das soll alles in Taps gar nicht sichtbar sein zu der Anwendung. Außerdem wollen wir gerne Datentransfer über Nachrichten machen. Eigentlich sind alle Anwendungsprotokolle heutzutage in Nachrichten gut HTTP funktioniert über TCP, aber die Apps da splitten wir es in Chancs auf. Also, ja, jedenfalls... Wir wollen nicht die unterliegenden Transporte ändern und das ist auch der Grund, dass mit existierenden Systemen funktionieren wird, weil wir nichts ändern. Es gibt auch bestimmte Dinge, die von den aktuellen APIs gar nicht gezeigt werden, so was wie Deadlines, also dass man Pakete gar nicht mehr anschaut, wenn er Empfänger gar nicht mehr damit anfangen kann und die Möglichkeit, unzuverlässige Nachrichten zu senden und das kann man dann pro Nachricht auswählen, was man davon möchte. Also, man kann dann auch für Multiverbindungen aussuchen, welche Verbindungen das jetzt benutzt. Wenn man heutzutage in ein Website aufruft, dann macht der Browser mehrere Verbindungen aus und nimmt einfach die schnellste. Das können wir heute dann in der Socket-API machen. Wir brauchen das nicht mehr in der Anwendung implementieren. Wie funktioniert das? Es gibt zwei Konzepte dafür. Einmal die Rahmenhersteller Framers. Framers erlauben die Nachrichten so oft zu splitten, dass es über ein Stream funktioniert, über ein Byte Stream. Hauptsächliche Anwendung davon ist, dass man über Nachrichten, über ein Stream schicken kann, über ein Streamprotokoll. Das kann man einfach in einem einfachen und sinnvollen Weg implementieren. Das könnte man eigentlich gut integrieren mit Flusskontrolle und anderen Features von TCP. Und schließlich das jetzt hauptsächlich dafür da, um Streamprotokoll als Nachrichtenprotokoll zu verwenden. Und vielleicht kriegen wir da auch noch andere Sachen unter. Wie kontrollieren wir das alles? Wir machen das über Transporteigenschaften. Wir haben Eigenschaften, die den Pool von Verbindungen einschränken, die wir benutzen können. Verbindungseigenschaften und Nachrichteneigenschaften, das wollen wir dann in so einem dictionary-ähnlichen Interface machen. Wir haben Namensräume für Erweiterungsfähigkeit, z.B. TCP-Punkt, so kann man einfache Eigenschaften haben, die nur verwendet werden für TCP, z.B. TCP-Punkt. Wie funktioniert das dann? Wenn wir das als Text darstellen, dann sagt die Anwendung, ich möchte eine Verbindung zu example.org mit dem Service HTTPS ein zuverlässigen Transfer und bittes, wir wollen eine geringe Rundlaufzeit, eine geringe Latency. Und das TAP-System sagt dann, ja, hier ist so deine Verbindung. Du kannst damit jetzt Nachrichten empfangen und senden und du brauchst dich nicht um Protokolle und Fade ändern. Es gibt dort dieses nette ASCII-Diagramm von dem aktuellen Draft, von der aktuellen Entwurf. Das ist hier ungefähr die Idee. Man startet mit einer Vorverbindung, darauf macht man ein bisschen Konfiguration. Man sagt, wo man ist, wo man hin möchte, z.B. in Hostname, Selektionen und Verbindungsoptionen. Man kann z.B. sagen, selbst wenn ich einen zuverlässigen Transport kriege, möchte ich alles unzuverlässig senden. Es ist mir egal, dass ich das habe. Dann gibt es, dann mit dem Preconnection-Objekt kann ich ein Initiate aufrufen, um eine Connection zu kriegen oder Listen aufrufen, um Listener-Object zu kriegen. Nach der Initiation kriegt man ein Event und Verbindung aufgebaut oder Verbindung empfangen. Damit kann man dann Send aufrufen, um Nachrichten zu senden. Man kriegt Nachrichten empfangen Events und wenn man schließt, dann geht es zum geschlossenen Zustand. Wie sieht es dann in Abstrakten-Code aus? Wir haben einen Remote-Specifizierer, also sagen wir Example.com mit dem Service HTTPS. Wir haben Transporteigenschaften zuverlässig und ein Stream, dann sagen wir noch zufällig, dass wir eine geringe Latency haben wollen. Dann sagen wir ein bisschen Sicherheitsparameter haben für die Verschlüstung und dann kriegen wir daraus eine Vorverbindung. Dann sagen wir hier, wir packen den HTTP-Framer rein, sodass man die HTTP-Antworten als Nachrichten kriegt und nicht als Dinge, die man rauspassen muss. Dann sagt man initiate und dann kriegt man irgendwann das Event, dass die Verbindung da ist. Dann kriegt man, dann kann man eine Nachricht bauen mit einer gewissen Live-Lebensdauer und dann können wir mit der Verbindung diese Nachricht senden. Wenn ihr Studenten von mir seid dann habe ich hier so ein Beispiel, wie man das bauen kann. Das habe ich jetzt aufgrund der Socket-API gemacht und das ist jetzt der gleiche Code wie in zwei Slides. Wir sind nicht die einzigen Implementierung, das gibt auch noch die viel vollständigere Apple-Frame-Work davon. Die ist verfügbar seit iOS 12 oder so und in 13 ist es ja noch richtig da als Standard-Verbindung und es basiert auf den Ideen von Tabs. Es gibt noch ähnliche Projekte, Needs und Socket-Intents. Die haben ein bisschen Input gegeben in den Prozess. Die haben so ein bisschen uns gezeigt, was man so ein Tab-System schaffen kann. Aber wenn man Tabs heute nutzen möchte, dann nehmt ihr die Apple-Frame-Work, wenn ihr iOS macht. Aber ja. Wenn ihr interessiert seid an noch mehr Zeugs, die Dokumente sind im Data Tracker des ITF, hier ist die URL. Wenn ihr mitarbeiten wollt, dann geht auf die Mailing-Liste. Wir lieben es, wenn ihr eure Meinung abgibt. Wenn ihr seht, dass es da Probleme gibt, dann schreibt uns einfach, wir wollen wirklich die nächste Generation der Verbindungs-APIs dort schreiben. Wenn ihr wissen wollt, was die kürzeste Diskussion ist, da haben wir die meisten detaillierten Diskussionen und irgendwelchen Issus auf GitHub. Wenn ihr irgendwo ein Rechtrepp hier gefunden habt, macht einfach GitHub-Isschie auf. Damit bin ich jetzt fertig mit meinem Talk. Und ich würde, ich frage nach Fragen. Hallo. Hi. Sorry, we just had a technical problem. Wir hatten gerade ein kleines Danger-Problem. Vielen Dank. Wir haben noch eine kurze Zeit für Fragen. Also bitte nicht schüchtern, einfach an die Mikros kommen. Thank you. You mentioned that the new APIs supposed to include deadlines are these real deadlines or just not? Sind das harte deadlines oder sind das Timeouts? Sehr gute Frage. We don't think that anyone will be implemented in a real-time working API because that's the real-time network API. Das ist sehr, sehr hart. Wenn man in deterministischen Netzwerksverbindungen geht, kann man das umsetzen, aber es ist sehr, sehr schwierig. Und das meiste ist einfach ein Vorschlag, also das nennt es Advisory. Im Prinzip misst man einfach die Zeit in dem Stack verbracht haben und wenn die Zeit überschritten ist, dann wird das abgeschnitten, aber wir denken eher über Message Timeouts nach. Thank you so much. Next question, please. Nächste Frage. Also in deinem Pipenbeispiel hast du gewartet auf das Send und hast dann ein Callback registriert auf dem Receipt, nach dem du mit Send gewartet hast und es sah ein bisschen merkwürdig aus. Warum muss ich denn warten auf das Send, wenn ich sowieso Callbacks verwende? Du musst eigentlich nicht mehr warten, das war einfach nur ein Beispiel, aber man muss eigentlich nicht warten, nee. Ah, und maybe a related question. Ach, verwandte Frage. Du hast gesagt, ihr wollt Protokoll unabhängig sein und offensichtlich, da sind verschiedene Nachrichten, Muster, die jenseits von bidirektionalen Beid beströmen sind. Wollt ihr da auch irgendwas anderes machen? Objektorientiert, Broadcasting oder sowas? Und wie ich schon in dem Vortrag gesagt habe, wir schauen wirklich nur Nachrichten an, ob es möglich ist oder nicht. Der Standard sollte sein, dass wir Nachrichten schicken und Beidströme werden in Nachrichten zahackt und dann verschickt. Das soll euch auch erlauben, dass man von TCP auf ein echtes nachrichtenbasiertes Protokoll umsteigen könnte. Wenn man jetzt Punkt-zu-Punkter-Bindung anschaut, dann haben wir Leute, die unsere Working Group beigetreten sind, die sich sehr dafür interessieren für Quellen spezifischen Multicast. Und wir wollen auch vollen Multicast-Support in unserer API, aber das ist immer noch relativ früh. Soweit sind wir noch nicht sowohl in Implementierungen als auch in der Standardisierung. Und es ist auch unsere Agenda. Aber wir müssen das in einer schönen und vor allem portablen Weise implementieren. So, noch eine Frage? Vielen Dank für den Vortrag. Kannst du schon vorhersehen, wie viele von den Implementierungen im User-Mode sind und wie viele enden im Kernel? Also vor allem die Asynchronenteile, wo werden die Urlanden auf der Kernel oder auf der User-Seite? Spannende Frage. Also wenn ihr euch die Implementierungen anschaut, die schon existieren, dann die Python ist zum Beispiel nur ein Rapper, also eine einfach dünne Hülle um das andere drum. Die meisten Implementierungen machen nur im User-Mode und den Kernel-Mode brauchen sie nur für das Multiplexing. Und ich denke, das ist dann auch der Weg, den die anderen beschreiten werden. Auf der anderen Seite. So zu sehen, dass beides möglich ist. Wir hoffen, dass es in der Zukunft auch möglich ist, das zu ändern. Und wir starten halt mit einer Hülle um den PSD API und dass wir das dann hinterher abstrahlen können und uns wegbewegen von der alten API. So, vielen Dank an Phil. Und nochmal eine Runde Applaus, bitte. So, das war die Übersetzung des Talks.