ch2.slide

Cours PRR
Chapitre 2 - Introduction au langage Go

Patrick Lachaize
HEIG-VD / TIC
patrick.lachaize@heig-vd.ch

* Table des matières

- Le langage Go comparé à Java
- Ressources et développement en Go
- Bases du langage
- Héritage vs Composition
- Concurrence
- Programmation TCP-IP en Go

Crédits:

- [[http://gopl.io]] The Go Programming Language / Alan A. A. Donovan et Brian W. Kernighan
- [[http://talks.golang.org/2015/go-for-java-programmers.slide]] Go for Java Programmers / Sameer Ajmani
- [[http://talks.golang.org/2014/go4java.slide]] Go for Javaneros / Francesc Campoy

* Le langage Go comparé à Java

* Le langage Go

"Go is an open source programming language that makes it easy to build simple, reliable, and efficient software." -- [[http://golang.org]]

Créé par Google en 2007 pour des besoins internes par :
  Robert Griesemer, Rob Pike et Ken Thompson.

Prévu pour :

- logiciels serveurs, microservices
- montée en charge en exploitation ( 10⁶⁺ machines)
--> programmation concurrente

- montée en charge en génie logiciel ( 5000+ développeurs)
--> arborescence étendue de code source

Open source depuis 2009 avec une communauté très active
Langage stable depuis la version 1 début 2012

Utilisateurs de GO : "[[https://github.com/golang/go/wiki/GoUsers][golang.org/wiki/GoUsers]]"

* Beaucoup de points communs
- Descendance du C (langage impératif, accolades)
- Typage statique fort
- Ramasse-miette
- Contrôle des accès mémoire (références nulles, dépassement d'indice)
- Les variables sont toujours initialisées (zero/nil/false)
- Méthodes
- Interfaces
- Assertions sur les types (`instanceof`)
- Introspection (reflection)

* Go est différent de plusieurs façons
- La compilation produit un exécutable natif. Pas de VM
- Librairies incluses dans l'exécutable (link statique)
- Les fonctions sont manipulables comme des valeurs (first class function)
- Les fonctions peuvent avoir un état par capture de variables (closures)
- String est un type intégré, représenté en UTF-8
- Maps et array/slices : types intégrés
- Concurrence intégrée dans le langage (Goroutines et channels)

* Volontairement exclus du GO
- Pas de classes (types et structures comme recepteur)
- Pas systématiquement de constructeurs, getters/setters
- Pas d'héritage (plutôt de la composition)
- Pas de déclaration d'implémentation d'interface
- Pas d'exceptions (sauf pour les aborts)
- Pas d'annotations (mais des tags dans les structures)
- Pas de types génériques (toujours en discussion pour la v2)

* Pourquoi ces omissions ?
- La lisibilité du code est primordiale.
- En lisant le code, on doit comprendre ce qu'il fait de façon claire.
- On doit savoir facilement comment l'écrire pour qu'il fonctionne.
- Parfois une petite boucle vaut mieux qu'un appel de fonction inconnue

Plus d'infos sur les principes de conception du GO:

- [[http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html][Less is exponentially more (Pike, 2012)]]
- [[http://talks.golang.org/2012/splash.article][Go at Google: Language Design in the Service of Software Engineering (Pike, 2012)]]

* Premier exemple traditionnel

Main.java

.code -edit sources/hello/Main.java

hello.go

.play -edit sources/hello/hello.go

* Ressources et développement en Go

* Ecrire et exécuter du Go

Site officiel du Go : [[https://golang.org/][golang.org]]

- Playground (Play) : édition et exécution en ligne
- Un tour de Go (Documents / Learning GO / A tour of GO) : tutoriel et exercices de prise en main
- Installation du compilateur, des librairies et des utilitaires (Documents / Installing GO)
- Développer un projet (Documents / Learning GO / How to write Go code) : organisation du code, package, tests, git
- Outils de développement (Documents / Learning GO / Editor plugins and IDEs)
- Bonnes pratiques de programmation (Documents / Learning GO / Effective Go)
- Références, articles, vidéos, ...

* Compiler, exécuter, installer
- soit hello.go déclarant le package main et la fonction main

- Dans le dossier de hello.go, pour produire l'exécutable dans ce dossier
 $ go build hello.go
 $ hello

- Dans un sous-dossier du GOPATH : %GOPATH%/src/.../helloheig/hello.go
 $ go install
 $ %GOPATH%/bin/helloheig

Le dossier helloheig correspond au package main et à l'exécutable helloheig
- il peut contenir plusieurs fichiers déclarant des variables et des fonctions.
- peu importe dans quels fichiers elles sont réparties
- tous les fichiers de ce dossier doivent déclarer le package main
- peu importe le nom de ces fichiers (xxx.go)
- il doit y avoir une et une seule fonction main dans un des fichiers

* Renverser "Hello, Heig"

- fichier hello.go dans un dossier hello
.code -edit sources/helloheig/hello.go

- reverse peut être définie dans hello.go ou dans un autre fichier .go de ce dossier
.code -edit sources/helloheig/fonctions.go

* Reverse (avec une majuscule) dans un autre package
- Reverse définie dans un fichier de GOPATH/src/github.com/patricklac/prr/utils
Tous les fichiers du dossier utils déclarent le package utils. Pas de main
.code -edit sources/helloheig2pack/fonctions.go  /Package/,/FIN/

- main définie dans un fichier de GOPATH/src/github.com/patricklac/prr/hello
.code -edit sources/helloheig2pack/hello.go

* Si un package est dans un repo git
_go_get_déclenche_un_clone_et_un_build_install_

- clone dans GOPATH/src et installation du package dans GOPATH/pkg :
 go get github.com/patricklac/prr/utils

- clone dans GOPATH/src, installation du package utils dans GOPATH/pkg si pas fait précédemment, et de l'exécutable dans GOPATH/bin :
 go get github.com/patricklac/prr/hello

Avec cette dernière commande, si les packages sont dans des repos GIT distincts, les 2 sont clonés

_Mécanisme_dit_'GOPATH'_très_pratique_mais_tout_est_dans_le_GOPATH,_sauf_les_packages_standards_qui_sont_dans_le_'GOROOT'_
1 seul GOPATH par compte, pas de gestion de version
--> en cours de remplacement par les go modules

* godoc

- en local
 > godoc github.com/patricklac/prr/utils
 PACKAGE DOCUMENTATION

 package utils
    import "github.com/patricklac/prr/utils"

    Package utils define various functions for prr

 FUNCTIONS

 func Reverse(s string) string
     Reverse string rune by rune

- en ligne
[[http://godoc.org/github.com/patricklac/prr/utils]]

* Tests
- dans le dossier GOPATH/src/github.com/patricklac/utils: go test
- fonctions_test.go
.code -edit sources/helloheig2pack/fonctions_test.go

* Bases du langage

* Les types en Go (1/2)

-  nombres, booléen, chaines de caractères

	int, uint, int8, uint8, ...
	float32, float64, complex64, complex128
	bool
	string

- structures

	struct {
		Name string
		Age  int
	}

- tableaux et slices, map

	[]int, [3]string, []struct{ Name string }
	map[string]int

* Déclaration, affectation de variables
- variable globale package
 var mot string // chaine vide
 var mot = "hello" // inférence du type à string

- variable globale application
 // Même syntaxe mais nom de varable avec majuscule
 // A importer et référencer nom_package.Mot
 var Mot string // chaine vide
 var Mot = "Hello" // inférence du type à string

- variable locale (dans une fonction)
 var mot string // chaine vide
 mot := "hello" // raccourci de var mot = "hello"

- affectation d'une variable déclarée (dans une fonction)
 mot = "hello"

* Structures
- Champs (fields) accédés avec la notation "."
- Initialisables avec un littéral

 	var fred struct {
 		prenom string
 		age    int
 	}
 	fred.prenom = "Frédéric"
 	pat := struct {
 		prenom string
 		age    int
 	}{
 		"Patricia",
 		25,
 	}
 	max := struct {
 		prenom string
 		age    int
 	}{prenom: "Maxime"}

- Pour l'exportation, mettre les champs avec une  majuscule : Fred, Prenom, Age

* Tableaux et slices
.image sources/img/go-slices-usage-and-internals_slice-2.png
	jaune := [5]byte{'a', 'b', 'c', 'd', 'e'}
	bleu := jaune[2:4]
	// len: 2, cap: 3, contient: c d
	bleu = append(bleu, 'f')
	// len: 3, cap: 3, contient: c d f
	bleu = append(bleu, 'g')
	// len: 4, cap: 8, contient: c d f g

	rouge := make([]byte, 10, 20)
	// len: 10, cap: 20, contient 10 zéros binaires

* Maps

	ages := make(map[string]int)
	agesliteral := map[string]int{
		"Frédéric": 22,
		"Patricia": 25,
	}
	ages["Robert"] = 32

	delete(agesliteral, "Frédéric")

	ageR := ages["Robert"]
	ageP, ok := ages["Patricia"]

- Sets
   noms := make(map[string]bool)
   mots := make(map[string]struct{})

* Instructions conditionnelles
- if else avec initialisation
 if x:= f(); x == 0 {
  ...
 } else {
  ...
 }

- switch avec ou sans opérande
  switch lancePièce() {                                switch () {
  case "pile":                                         case x > 0:
     pile++                                                return 1
  case "face":                                         default:
     face++                                                return 0
  default:                                             case x < 0:
     fmt.println("sur le coté !")                          return -1
   }                                                   }

* Boucles
 for initialisation; condition; post {
  ...
 }

- Tous les opérandes sont optionnels
 for condition {  // boucle while
 for { // boucle infinie

- Boucle "foreach" avec range
 func main() {
 	s, sep := "", ""
 	for _, arg := range os.Args[1:] {
 		s += sep + arg
 		sep = " "
 	}
 	fmt.Println(s)
  }
Le "_" permet de ne pas récupérer l'indice de boucle

* Les types en Go (2/2)

- fonctions

	func(int, int) int

- pointeurs

	*int, *Person

- interfaces

	interface {
		Start()
		Stop()
	}

- canaux (channels)

	chan bool

* Déclarations de fonctions

	func [name] ([params]) [return value]
	func [name] ([params]) ([return values])

Fonction sum :

	func sum(a int, b int) int {
		return a + b
	}

Fonction avec plusieurs valeurs de retour :

	func div(a, b int) (int, int)
		return a / b, a % b
	}

Pour la clarté, valeurs de retour nommées:

	func div(den, div int) (q, rem int)
		return a / b, a % b // ou affecter q et rem puis return
	}

* Fonctions valeurs (first class function)
- les fonctions sont des types :

.play sources/fonctions/fonctions.go /square/,/end/
Un littéral de fonction  peut être affecté à des variables
On peut donc le définir à l'intérieur d'une autre fonction
Un littéral de fonction dans un paramètre en fait une fonction anonyme

* Closures
Les fonctions peuvent avoir un état (des données privées dans le 'heap')
.code sources/squares/main.go /squares/,/end/
Une fonction définie dans une fonction a accès aux variables de cette dernière
A l'affectation de f, la variable x est capturée avec le littéral de fonction retourné

* Capture de variables d'itération

    var rmdirs []func()
    for _, d := range tempDirs() {
        dir := d
        os.MkdirAll(dir,0755) // creates partent directories too
        rmdirs = append(rmdirs, func() {
            os.RemoveAll(dir) // la variable d ne peut pas être utilisée ici
        })
    }
    . . .
    for _, rmdir := range rmdirs {
       rmdir() // clean up
    }

La fonction passée à RemoveAll sera exécutée plus tard -> d aurait été écrasé





* Déclaration de nouveaux types

	type [name] [specification]

`Person` est un type basé sur un `struct`.

	type Person struct {
		name string
		age  int
	}

`fn` est un type basé sur une fonction

    type fn func(int) int

`Celsius` et `Fahrenheit` sont des types basés sur `float64`.

	type Celsius float64
	type Fahrenheit float64
	var celsiusBoue Celsius = 100
	var fahrenheitBoue Fahrenheit = celsiusBoue // pb compil : pas le même type

* Conversion de type
- Si même type de base par la notation: type(variable)

  func CToF(c Celsius) Fahrenheit { return Fahrenheit(c*9/5 + 32) }

- Entre types numériques
	var x float64 = 3.2
	var n int = 2
	n = int(x) // avec troncation, n = x ne compile pas
	x = float64(n) // x = n ne compile pas, pas de conversion implicite

- les string sont des []byte non modifiables : conversion en [ ]byte ou [ ]rune
   s:= "aéb" // utf8 : 8 --> 32 bits
   b:= []byte(s) // len: 4 (comme s) car é prend 2 bytes
   s2:= string(b)
   r := []rune(s) // unicode (32 bits), len: 3

_Une_conversion_de_type_ne_peut_pas_échouer_à_l'exécution_

* A ne pas confondre avec :

- Conversion string / int
   i, err := strconv.Atoi("-42")
   s := strconv.Itoa(-42)

- Assertion de type pour une interface: `valeur.(type)`
( équivalent de instanceof / cast en java )

    func lire(v io.Writer) {
        if w,err:= v.(io.ReadWriter); err {
            var b []byte
            w.Read(b)
            ...
        }
    }

_Certaines_de_ces_conversions_peuvent_échouer_à_l'éxécution_

* Déclaration de méthodes : fonctions avec récepteur

	func ([receiver]) [name] ([params]) ([return values])

Méthode sur un struct:

	func (p Person) Major() bool {
		return p.age >= 18
	}

Mais aussi méthode sur un `float64`:

	func (c Celsius) Freezing() bool {
		return c <= 0
	}

_Méthodes_définies_uniquement_sur_des_types_déclarés_dans_le_même_package._

    func (s string) Length() int {  	// Ne compile pas avec un string comme récepteur
        n := 0
        for range s { n++ } // pas passé par gofmt !
        return n
    }

* Pointeurs

Symbole `&` pour obtenir l'adresse d'un variable, `*` pour déréférencer un pointeur.

	a := "hello"
	p := &a
	fmt.Print(*p + ", world")

Pas d'arithmétique avec les pointeurs. Pas de pointeurs fous.

	p += 4  // non

new crée une variable anonyme et retourne un pointeur sur celle ci

    p := new(int)
    fmt.Println(*p) // 0

    p := newInt() // équivalent
    func newInt() *int {
        var dummy int
        return &dummy
     }

* Pourquoi des pointers ?

- passer des valeurs, pas d'effet de bord:

	func double(x int) {
		x *= 2
	}

- passer des pointeurs, effet de bord possibles:

	func double(x *int) {
		*x *= 2
	}

Maitrise de la disposition mémoire

-  [ ]Person différent de [ ]*Person

* Déclaration de méthodes sur des pointeurs

Un récepteur se comporte comme n'importe quel paramêtre.

Un pointeur permet de modifier le recepteur:

	func (p *Person) IncAge() {
		p.age++
	}

Le récepteur est une copie de pointeur (qui pointe sur la même adresse).

Les appels de méthode sur nil sont valides ( et utiles !)

	func (p *Person) Name() string {
		if p == nil {
			return "anonymous"
		}
		return p.name
	}

* Interfaces

Une interface est un ensemble de méthodes.

En Java:

	interface Switch {
		void open();
		void close();
	}

En Go:

	type OpenCloser interface {
		Open()
		Close()
	}

* Pas d'implémentation d'interfaces

Les interfaces en java sont satisfaites *explicitement*.

Les interfaces en java sont satisfaites *implicitement*.


_Si_un_type_définit_toutes_les_méthodes_d'une_interface,_il_satisfait_cette_interface._

Avantages:

- moins de dépendances
- pas de hiérarchie de types

* Exemple d'application d'une interface entre 2 packages (1/2)

_Soit_dans_package_parser_:_

La méthode `Parse` analyse une chaine de caractère et retourne une "fonction"

	func Parse(text string) (*Func, error) { ... }

`Func` est un type basé sur un struct, avec une méthode `Eval`.

	type Func struct { ... }

	func (p *Func) Eval(x float64) float64 { ... }

* Exemple d'application d'une interface entre 2 packages (2/2)

_Soit_dans_package_draw_:_

La méthode `Draw` génère la courbe d'une "fonction" donnée.

	func Draw(f *parser.Func) image.Image {
		for x := start; x < end; x += inc {
			y := f.Eval(x)
			...
		}
	}

`draw` depend de `parser`, cela rend entre autres les tests difficiles.

En définissant une interface dans le package draw :

	type Evaluable interface {
		Eval(float64) float64
	}

	func Draw(f Evaluable) image.Image { ... }

Rien à changer dans le package parser !

* Héritage vs Composition

* Runner (Java)

.code sources/heritage/BadInheritance.java /START_RUNNER/,/END_RUNNER/

* RunCounter est-un Runner avec un compteur

.code sources/heritage/BadInheritance.java /START_COUNTING/,/END_COUNTING/

* Laissons le courir et compter

L'exécution de :

.code sources/heritage/BadInheritance.java /START_MAIN/,/END_MAIN/

affiche:

	running one
	running two
	running three
	my runner ran 6 tasks

Pourquoi 6 ?

* Pourquoi 6 ?

A cause de l'héritage:

- encapsulation faible,
- couplage fort,
- bugs surprenants.

.image sources/img/badinheritance.png

* Solution: remplacer l'héritage par une composition

.code sources/heritage/Composition.java /START_COUNTING/,/BREAK_COUNTING/

* RunCounter (suite)

.code sources/heritage/Composition.java /BREAK_COUNTING/,/END_COUNTING/

* Une composition plutôt qu'un héritage

*Pros*

- plus de bugs!
- `Runner` is complètement indépendant de `RunCounter`.
- La création de `Runner` peut être repoussée jusqu'à ce que l'on en aie besoin.
- En typant runner avec une interface, on peut dynamiquement selectionner un type de Runner
- Cela facilite en particulier le  'mocking' pour les tests.

*Cons*

- On doit explicitement définir des méthodes de délégation dans `RunCounter`:

	public String getName() { return runner.getName(); }

* Il n'y a pas d'héritage en Go

type `Runner` similaire à la classe `Runner` en Java:

# .code sources/runner/runner.go /type Task/,/END_TASK/

.code sources/runner/runner.go /type Runner/,/END_RUNNER/

Utilisons la composition -->

* RunCounter avec composition d'un Runner

`RunCounter` définit une variable `Runner`.

.code sources/runner/runner.go /type RunCounter/,

* Struct embedding

Dans le code précédent, on a toujours la méthode de délégation vers `Runner`:

.code sources/runner/runner.go /runner.Name/

Mais on peut s'en passer avec le 'Struct embedding'

On peut définir en Go des variables anonymes dans les structures. Cela revient à incorporer le type de ces variables dans les structures.

C'est toujours de la *composition*, mais les variables et les méthodes définies dans ces types sont également automatiquement définies dans les structures qui les incorporent.

Cela ressemble à de l'héritage mais les types incorporés sont réellement indépendants des structures qui les incorporent..

* Exemple de 'struct embedding'

Soit un type `Person`:

.code sources/heritage/embedsample.go /Person/,/Hi/

On peut définir un type `Employee` incorporant `Person`:

.code sources/heritage/embedsample.go /Employee/,/}/

Toutes les variables et méthodes de `Person` sont disponibles dans `Employee`:

.code sources/heritage/embedsample.go /var/,/Introduce/

* Plus besoin de Name() dans RunCounter2

.code sources/runner/embed.go /type RunCounter2/,

* Exemple avec incorporation d'une interface

.code sources/heritage/writecounter.go /WriteCounter/,/MAIN/

writecounter peut être utilisé avec n'importe quel `io.ReadWriter`.

.play sources/heritage/writecounter.go /func main/,/^}/

* Autre exemple: faciliter un 'mocking'

Simuler seulement certaines méthodes de `net.Conn`

	type Conn interface {
	        Read(b []byte) (n int, err error)
	        Write(b []byte) (n int, err error)
	        Close() error
	        LocalAddr() Addr
	        RemoteAddr() Addr
	        SetDeadline(t time.Time) error
	        SetReadDeadline(t time.Time) error
	        SetWriteDeadline(t time.Time) error
	}

afin de tester `handleCon` ?

.code sources/heritage/loopback.go /handleCon/

On peut créer un type 'fakeConn' pour remplacer 'Conn' mais il faudrait redéfinir toutes les méthodes de  `Conn` dans 'fakeConn' pour pouvoir le passer à 'handleConn'

* Plutôt incorporer l'interface Conn

On peut tester `handleCon` avec le type`loopBack`:

.code sources/heritage/loopback.go /loopBack/,/^}/

On n'y définit que les méthodes utilisées :

.code sources/heritage/loopback.go /Read/,

et loopBack satisfait Conn

* Concurrence


* Communicating Sequential Processes (Hoare, 1978)

Les programmes concurrents sont structurés comme des processus indépendants qui s'exécutent séquentiellement et qui communiquent par échange de messages

L'exécution séquentielle est facile à comprendre, pas les callback asynchrones.

"Don't communicate by sharing memory, share memory by communicating."

*Primitives*intégrées*en*Go:* goroutines, channels, et l'instruction `select`.

* Goroutines

Les Goroutines sont comme des threads mais plus légères.

Elles démarrent avec peu de mémoire et s'étendent si besoin.

Les programmes en GO peuvent en gérer des centaines de millier.

Démarrage d'une goroutine par l'instruction `go` :

  go f(args)

Go réparti les goroutines sur les threads de l'OS.

Une goroutine bloquée ne bloque pas un thread.

* Canaux (Channel)

Les canaux permettent la communication entre les  goroutines.

  c := make(chan string)
  // goroutine 1
  c <- "hello!"
  // goroutine 2
  s := <-c
  fmt.Println(s) // "hello!"

- Par défaut, un channel n'a pas de buffer et bloque aussi à l'émission
  c := make(chan string)
  // nouvelle goroutine
  go func() {c <- "hello!"}()
  // goroutine "main"
  s := <-c
  fmt.Println(s) // "hello!"

_Attention:_si_main_"termine",_toutes_les_goroutines_sont_abortées_

* Select

  select {
  case n := <-in1:
    fmt.Println("received sur in1", n)
  case n := <-in2:
    fmt.Println("received sur in2", n)
  case out <- v:
    fmt.Println("sent sour out", v)
  }

- L'instruction `select` bloque jusqu'à ce qu'une communication ait lieu, sauf si option default.
- Seule une option du select s'exécute. Un select est souvent pris dans une boucle.

* Exemple: simulation de recherches sur Google


Des fonctions Web, Image, Video (de type Search) :
- à partir d'une requête en paramètre (query)
- recherchent dans une catégorie capturée (kind) : "web2, "image", "video"
- retournent des liens (Result), ici un simple message de fin de recherche
- après un certain temps, simulé avec un  tirage aléatoire

.code sources/google-search/google-serial.go /START2/,/STOP2/

* Recherches séquentielles

La fonction Google lance séquentiellement des recherches Web, Image et Video.
Elle retourne les résultats cumulés dans un slice.
.code sources/google-search/google-serial.go /START1/,/STOP1/

Un main pour l'essayer :
.play sources/google-search/google-serial.go /func.main/,/}/


* Recherches parallèles

.play sources/google-search/google-parallel.go /Google/,/^}/

Conversion facile: go func, channel

Les recherches sont exécutées concurremment mais les résultats sont envoyés un à un dans le channel c, puis récupérés un par un dans la boucle for

Il n'y a qu'une goroutine qui accède au slice results : pas besoin d'autre synchronisation

_pas_de_locks,_pas_de_variables_conditionnelles,_pas_de_callback_

* Recherches avec timeout : ne pas attendre les serveurs lents.

.play -edit sources/google-search/google-timeout.go /START/,/STOP/
L'instruction select permet de gérer les timeout, done, abort, ...
Notez le passage du channel c à 3 buffers pour _délivrer_ les goroutines encore en exécution après timeout. Problème du "goroutine leak".
Le channel n'est pas vidé mais plus de goroutines en attente dessus : une nouvelle requête en crée un autre et l'ancien passe au ramasse-miettes.

* Autre exemple : distribution d' ids par un serveur Web

On reçoit les ids sur un channel.

.code sources/heritage/goodcounter.go /nextID/,/^}/

main les envoie sur ce channel : _pas_de_compteur_partagé,_pas_de_lock,_..._

.play sources/heritage/goodcounter.go /func main/,/^}/

C'est tout ? Oui : [[http://localhost:8080/next]]

* Pour en savoir plus sur la concurrence en GO

- [[http://talks.golang.org/2012/concurrency.slide#1][Go Concurrency Patterns]], by Rob Pike
- [[http://talks.golang.org/2013/advconc.slide#1][Advanced Concurrency Patterns]], by Sameer Ajmani
- [[http://talks.golang.org/2012/waza.slide#1][Concurrency is not Parellelism]], by Rob Pike


* Programmation TCP-IP en Go

* Client UDP
.code sources/udp/udpclient.go /debut/,/fin/
defer reporte un appel de fonction en fin de méthode, dans tous les cas de sortie
Conn satisfait l'interface ReadWriter : on peut le copier ligne à ligne comme un fichier

* Serveur UDP
.code sources/udp/udpserver.go /debut/,/fin/
ListenPacket plutôt que Listen rend un PacketConn avec ReadFrom et WriteTo

* Multicast UDP (1/2)

.code sources/udp/udpmulticast.go /debut/,/milieu/
Les adresses entre 224... et 239... sont réservées au multicast
L'émission est la même qu'en unicast, mais diffusion par les routeurs à tous les clients en écoute sur la même adresse

* Multicast UDP (2/2)
.code sources/udp/udpmulticast.go /milieu/,/fin/
"golang.org/x/net/ipv4" permet, avec son PacketConn, le multicast avec écho local

* Client TCP (netcat)
.code sources/chat/netcat.go /debutMain/,/finMain/
io.copy(dst io.Writer, src io.Reader) // copie ligne à ligne jusqu'à ctrl-D, close ou erreur
2 goroutines : fonction littérale pour la reception (1) , main pour l'émission (0)
ctrl-D -> (0) close -> close du serveur -> (1) log "done" -> (1) envoi dans channel done -> (0) reception dans channel done -> fin d'exécution

* Server TCP (chat)

.code sources/chat/chat.go /debutMain/,/finMain/

main écoute sur un port et accepte les connexions client
Pour chaque client, il crée un goroutine handleConn pour s'occuper de la communication avec celui-ci, ce qui permet de les traiter concurremment
Parallèlement, il crée une goroutine broadcaster qui va gérer les communications entre les handleConn

* Server TCP: channels pour broadcaster()

.code sources/chat/chat.go /debutChannel/,/finChannel/

channels de channels ...

Un `client` est un type de channel dans lequel broadcaster enverra des messages à un handleConn, donc à un client
La notation "chan<-" limite son utilisation par broadcaster à l'envoi
Il y aura un channel client par handleConn, donc par client

`entering` est un channel pour obtenir les nouveaux channels client à leurs connections
`leaving` permet de savoir lorsqu'un client quitte

'messages' permet la reception des messages "texte" des handleConn


* Server TCP: broadcaster()

.code sources/chat/chat.go /debutBroad/,/finBroad/

_C'est_la_seule_goroutine_à_travailler_avec_le_set_clients:_pas_de_lock..._

* Server TCP: handleConn()

.code sources/chat/chat.go /debutHandle/,/finHandle/

* Exercice

- Modifiez le serveur TCP de chat pour limiter le nombre de client simultanés

Limite fixée par une constante dans le code

Si la limite est atteinte, un message signale au client qu'il doit patienter

Lorsque le client est admis, un message le lui signale

- Tips
Un channel à nil dans le case d'un select n'est jamais sélectionné
Vous pouvez dynamiquement affecter un channel ou nil dans le case d'un select

- Le code source à modifier :
 go get github.com/patricklac/prr/tcp