wybiral/hookah

Add UDP?

Closed this issue · 5 comments

wybiral commented

Should UDP be an option? If so, how do we resolve the issue of symmetry with the rest of the API? So far every protocol supports all four scenarios but with UDP it gets weird...

hookah -i udp://server:port
This kinda makes sense if the server already knows the address of the client to send to. Just connect and read all incoming messages.

hookah -o udp://server:port
This is easy, just send the messages to the server.

hookah -i udp-server://server:port
This is easy, just accept all incoming messages.

hookah -o udp-server://server:port
This is weird because we don't have an easy way to send the messages to all clients.

Does anyone else have any thoughts on this?

arl commented

Nice package!
Just my 2c.
For the last case, -o udp-server, UDP multicast maybe?

wybiral commented

Thanks!

UDP multicast maybe

I agree, multicast would be good to support. But it might be confusing to use the UDP-server proto for it.

https://godoc.org/net#ListenMulticastUDP

It would probably only work to have -i udp-multicast:// because the normal -o udp:// would still be the one responsible for dialing the multicast address.

With UDP protocols the client usually has to send some kind of request, which shares its address, before receiving messages from the server. Unless I'm overlooking something here.

  • udp://
    • works for -o (and kinda for -i)
  • udp-server://
    • works for -i
  • udp-multicast://
    • works for -i

UDP may need to be inconsistent in the rest of the API since it isn't symmetrical.

arl commented

With UDP protocols the client usually has to send some kind of request, which shares its address, before receiving messages from the server. Unless I'm overlooking something here.

You are right, for an UDP server to reply to a client, it requires an address/port, either sent by the client via some kind of protocol, or agreed beforehand between both parties.

UDP may need to be inconsistent in the rest of the API since it isn't symmetrical.

It seems so. I don't have other examples in mind but I'm sure there are other examples of protocols for which writing and reading are not symmetrical. BTW it would be nice to be able to provide custom protocols when using hookah as a package, for example with a simple API like:

var custom Proto // implements io.ReadCloser + a way to provide options
hookah.registerInput("myproto", custom)

And be able to use it with myproto://foo=bar.
I don't have any use case for it though :-)

  • 👍1
wybiral commented

I completely agree with the idea of a RegisterInput / RegisterOuput API.