2015-02-26 17:02 GMT+01:00 Antoine Pitrou <[email protected]>: > Are you implementing the server?
Yes. > I think a "stream"-like functionality > would be mostly useful for clients. A server is better suited to the > traditional Protocol idiom IMHO. I really hate the protocol API. It's too hard to use it for my little head. I prefer a regular question-answer code, what I call "sequential" code: --- data = sock.recv(100) ... sock.send(reply) --- in asyncio, it's written something like: --- data = yield from reader.recv(100) ... writer.write(reply) yield from writer.drain() # optional --- asyncio supports streams for the server side. See the "TCP echo server using streams" example: https://docs.python.org/dev/library/asyncio-stream.html#tcp-echo-server-using-streams You can compare it to the protocol version: https://docs.python.org/dev/library/asyncio-protocol.html#asyncio-tcp-echo-server-protocol > In any case, in UDP you want the server to send a response to the > client (if only a "ACK"); otherwise the client doesn't know whether the > message was received or not. In the specific case of Ceilometer: there is no ack, the server only consumes input packets and dropped packets are ignored. It doesn't really matter if a few packets are lost. For example, Ceilometer can be used to store the CPU usage. It doesn't matter if you loose some points. Victor
