🚀 go-pugleaf

Johan Vervloet wrote:

> Hallo,
> 
> Ik zou zo graag eens experimenteren met netwerkprogrammeren, en ik ben van
> plan een simpel serverapplicatietje te schrijven voor mijn linux pc, met
> de volgende functionaliteit:
> 
>  - connecties aanvaarden van meerdere clients tegelijk
>  - boodschappen ontvangen van clients
>  - boodschappen sturen naar clients

Wat je concreet wil doen is select(en) op een aantal connecties. Het
principe is eenvoudig.

Jij opent X aantal connecties. Deze zijn genummerd. Enkele voorbeelden
        -> 8 : een connectie die toelaat dat clients connecteren op poort 80
        -> 15: een connectie localhost:5789:jan-met-de-pet:8767 voor jan zijn
browser
        -> 31: een connectie localhost:9822:hanne.telenet:1241 voor hanne

Select zegt tegen het besturingssysteem "als er een connectie komt op een
van deze poorten (die je dan bij nummer noemt), dan verwittigd ge mij". Hoe
werkt dat concreet ?

open_connectie1();
open_connectie2();
open_connectie3();

van deze aanroepen krijg je een nummer terug, dat je moet bijhouden (de
return waarde van de socket() syscall) ...

Dan kan je op die getallen selecten (de manpage bevat een mooi voorbeeld),
en als die functiecall returned dan kan je zien op welke connecties er
activiteit is geweest, dan handel je die activiteiten af (bv ... er zijn
verse bytes binnengekomen -> reply sturen).

Dit noemt asynchroon programmeren, als het over gui's gaat ook wel
event-based programmeren genoemd, door tegenstanders ook soms "de visual
basic manier" ;-p. 

Als je een toolkit als QT of GTK gebruikt, dan werk je automatisch op deze
manier (de qt QApplication::exec doet o.m. een select).

Het alternatief voor asynchroon programmeren is multithreaded programmeren,

Asynchroon programmeren is efficienter dan multithreaded (geen context
switches)*, en eenvoudiger (geen locking benodigd, geen concurrency
issues**).

Het moet wel gezegd worden dat op extreme schaal multithreaded programmeren
het begint te winnen van asynchroon. Zeker in talen als java (met een
multithreaded vm) is het een pak simpeler en sneller van threaded te
werken, omdat je met tasklet achtige dingen kan werken (een threadje dat je
aanmaakt en weggooit).

Ik hoop dat ik je een beetje verder geholpen heb.

groeten

Oelewapperke

* bij bepaalde workloads kan je je hierover vragen beginnen te stellen wel
** behalve natuurlijk, als je daar zelf voor zorgt, gewoon in de gaten
houden dat je echt wel request-per-request moet werken, een half request
MOET je bufferen of je hebt het waarschijnlijk zitten