Closed aklinkert closed 5 years ago
To be very honest, I dont rember the ins and outs of opCode anymore. I seem to remember that opcode has different endianness for some packets. I will have to take a look at the binary spec again to know what is was about again.
If you can simplify then I am all for it. If you wish to bounce ideas Id be happy to help.
If you are interested, me and several excellent developers hang out in #networking in the Gophers Slack, https://invite.slack.golangbridge.org/
Would you consider this issue resolved with #10?
Yes, definitely. The endianness handling now limits to validate
and finish
method of each header.go
and artpollreply.go
, and the artpollreply.go
has explicit comments stating why we have to handle it separately. 💪
Within the
artpoll
,artpollreply
,header
andpacket
files the opCode is converted from little to big endian and vice versa multiple times which makes it pretty confusing during development and debugging to understand when and why the conversion is done. I tried to start cleaning that up but wanted to hear your opinion on that before putting too much effort on that, as I would lean to refactor and centralise the generic packet handling. So, any thoughts on that?