Servidor e cliente Toy UDP em Go. Fiz isso para me familiarizar com o pacote padrão net
do Go, especificamente com as funções relacionadas ao UDP.
Porque aprendi enquanto escrevia, aqui está uma estranha incompatibilidade estilística entre como server.go faz soquetes UDP e como client.go faz alguma coisa de soquete "geral". Para conciliar essa incompatibilidade, fiz client2.go apenas com funções UDP para corresponder a server.go.
Também adicionei um cliente Python 3, porque não tenho mais onde colocá-lo.
O servidor escuta pacotes UDP em um número de porta específico. Ele bloqueia a chamada do método net.ReadFromUDP()
.
Caso o servidor receba bytes, ele imprime quantos bytes recebeu de onde e depois grava esse mesmo número de bytes de volta para onde quer que os tenha recebido.
O cliente cria uma conexão UDP com algum IP (v4 ou v6) ou nome de host e um número de porta, com base nas informações da linha de comando. Em seguida, ele grava bytes de uma string, também da linha de comando, na conexão UDP. Ele espera até que alguns bytes retornem ou ocorra um erro. Então existe.
Simples, mas cheio de problemas. Sem tempos limite, sem número definido de bytes. O cliente ou servidor pode ficar para sempre esperando por um pacote que nunca chega.
$ go build server.go
$ go build client.go
$ go build client2.go
O cliente python 3 é interpretado e não precisa de "construção".
Na janela 1:
$ ./server :: 7890
Accepting a new packet
Na janela 2:
$ ./client udp localhost 7890 'some string'
Ou:
$ ./client2 fe80::a11:96ff:fe7f:6d74 7890 'some string' [eth0]
Ou:
$ ./client1.py localhost 7890 'some string'
O argumento final de ./client2
é opcional. É o nome da interface de rede pela qual rotear os pacotes. Observe o conteúdo de net.UDPAddr
:
type UDPAddr struct {
IP IP
Port int
Zone string // IPv6 scoped addressing zone
}
O elemento Zone é usado para rotear endereços locais de link (fe80: prefixo). O nome da interface funciona como a zona. Chamado com um quarto argumento, client2
usa esse argumento como a "zona".