122 lines
3.6 KiB
Markdown
122 lines
3.6 KiB
Markdown
Grote lijnen
|
|
============
|
|
|
|
Een collaborative challenge waarin de teams samenwerken om zo veel
|
|
mogelijk challenges te completen waarvoor ze specifieke features nodig
|
|
hebben in hun HTTP-clients en -servers. Wij hebben op voorhand een
|
|
server geconfigureerd die de huidige stand van zaken bijhoudt, en waarop
|
|
challenges ingediend kunnen worden (zie verder). Vanaf bepaalde
|
|
thresholds bereikt worden, zouden er rewards tegenover staan.
|
|
|
|
Conceptuele aandachtspunten
|
|
===========================
|
|
|
|
- Er moet een grote voorstelling zijn van de progress-bar die ergens
|
|
> publiek zichtbaar is. Dit kan zowel op de gebruikte server/site,
|
|
> als hardware-matig (meer werk) (denk een opvullende meetbuis).
|
|
|
|
- Het moet makkelijk te zien zijn hoe de challenges origineel verdeeld
|
|
> zijn onder de teams, en welke challenges al voltooid zijn, dit om
|
|
> toe te laten sterke teams meer werk op te nemen, en te vermijden
|
|
> dat zwakke teams in de problemen komen. Maw, de hoeveelheid op te
|
|
> nemen werk is veel dynamischer.
|
|
|
|
- Alle rewards horen groepsgebonden te zijn, dit om te vermijden dat
|
|
> er om de 'makkelijke' challenges gevochten wordt.
|
|
|
|
- De challenges horen klein en modulair te zijn, zodat makkelijk
|
|
> incrementeel gewerkt kan worden, en de instapdrempel verlaagd
|
|
> wordt.
|
|
|
|
Server-eigenschappen
|
|
====================
|
|
|
|
Strakke interfaces zijn leuk en professioneel. Zoals reeds vermeld is
|
|
een grote focus op de vooruitgang van het geheel. Verder is er een
|
|
duidelijk overzicht nodig van de challenge-statussen (ASSIGNED TO,
|
|
COMPLETED, BUSY, REQUESTED, ...). Dit is ons MVP, en kan in principe
|
|
heel simplistisch geïmplementeerd worden (desnoods met publieke
|
|
spreadsheets) en een progress bar site. Een kleine dedicated server zou
|
|
echter wel op zijn plaats zijn.
|
|
|
|
Verder moet de server ook een aantal triggers proccen als er bepaalde
|
|
requests naar toe gestuurd worden, dit zouden dan de challenges zijn, en
|
|
de meter omhoog doen gaan. Om ook server-related uitdagingen te hebben
|
|
zou de server met speciale requests kunnen pollen op enkele ip-adressen
|
|
die dan online zouden kunnen worden ingegeven.
|
|
|
|
Challenges
|
|
==========
|
|
|
|
Kleine, losstaande uitdagingen die een bepaald aspect van het HTTP
|
|
protocol zouden moeten verkennen. Voor concrete ideeën moet ik mijzelf
|
|
wat verdiepen in de HTTP-specs, maar er lijken mogelijkheden genoeg te
|
|
zijn. Voorbeeld: laat je client een request sturen waarin een bepaalde
|
|
image zit.
|
|
|
|
TODO: Challenges oplijsten
|
|
|
|
Gegeven:
|
|
|
|
- De HTTP-specs
|
|
|
|
- Een lijst van wijzigingen aan de URL- en HTTP-specs naar het
|
|
> Pizza-protocol
|
|
|
|
- Dit om te vermijden dat bestaande libs gebruikt worden
|
|
|
|
- Bv: in plaats van GET doen we ORDER
|
|
|
|
- Bv: in plaats van http://example.org/bla\#foo wordt het
|
|
> 🍕:org.example🍴bla🍝foo
|
|
|
|
<!-- -->
|
|
|
|
- Een start-URL
|
|
|
|
Toegestaan:
|
|
|
|
- TCP-library
|
|
|
|
- DNS-library
|
|
|
|
Verboden:
|
|
|
|
- URL-library
|
|
|
|
- HTTP-library
|
|
|
|
Ruben's quick ideas (in opklimmende moeilijkheid):
|
|
|
|
- TCP-connectie maken met het IP-adres op poort 80
|
|
|
|
- Eerste requestregel correct (GET /)
|
|
|
|
- Request met Host: header correct
|
|
|
|
- Meerdere headers meesturen
|
|
|
|
- Parsen van de response headers
|
|
|
|
- Parsen van de response body
|
|
|
|
- Een POST request sturen
|
|
|
|
- Een gegzipte response body ontvangen
|
|
|
|
- Een gegzipt POST request opstellen
|
|
|
|
- Meerdere requests over een enkele connectie sturen
|
|
|
|
- Een koffie bestellen als dessert
|
|
> ([[https://tools.ietf.org/html/rfc2324]{.underline}](https://tools.ietf.org/html/rfc2324))
|
|
|
|
- ...en tot slot, enkel als al het bovenstaande werkt: een gewoon
|
|
> HTTP-request met dezelfde client (maar nog steeds de pizza-URL, om
|
|
> valsspelen tegen te gaan).
|
|
|
|
Rewards
|
|
=======
|
|
|
|
TODO
|