crgimenes / go-osc

Open Sound Control (OSC) library for Golang. Implemented in pure Go.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Multi client support

BeKuBa opened this issue · comments

Add a new feature to handle multiple clients:

  • change signature of HandlerFunc to func(msg *Message, addr net.Addr)
    This is a api change. But adapt projects is very simple. The behavior don't change
  • Add SendTo... functions for sending response

Have a look at https://github.com/BeKuBa/go-osc/tree/multiclient-support

Can you explain better ? Why we need to add addr to HandlerFunc ?

E.g. you are the OSC server and you want send a response message to the client.
If you have more than 1 client you need the addr to send the response to the requested client.

Yes, I understood this. And agree with you. But why MsgHandler needs this information?. We have 1 server, so the server object must have all informations. When a new client connect to the server, this last one saves that information for the future SendTo method. MsgHandler mustn't know anything about server, ip address and others, it must handle the message only.

I think the MsgHandler is the best place for the client IP(with port). What you describe don't work if the communication is not blocked. That means: If you save the client adr on the server you have no guarantee that the adr suite to the message.
Also http libs such as httprouter use a responsewriter.
https://github.com/julienschmidt/httprouter
...
func Hello(w http.ResponseWriter, r *http.Request, ps httprouter.Params) {
fmt.Fprintf(w, "hello, %s!\n", ps.ByName("name"))
}
....
Use the adr is a easy way to handle the response with more than 1 clients.

The pattern you mentioned, however, keeps all the logic inside the handler, So the server doesn't know anything. While in the implementation you provided, https://github.com/BeKuBa/go-osc/tree/multiclient-support, you create a SendTo method that is called by the server. So there are only two solutions: either you move everything to the server or instead of just passing the Addr, you can create a resonsewriter-style object.

You are right. To use the Addr you need the ServerAndClient object. The Server object can't use it for response, only for log ... . In my opinion you should use only the ServerAndClient object for new projects, for both for OSC server and OSC clients. I implement this so, to make it backward compatible. The only breaking change is the signatur of the handle function. But this is simple to handle.
To implement a reponsewriter object seems too complicate to me.

My version for "multi client support" is ready for PR.
It is backward compatible. I add the new function "HandlerFuncExt" and change something under the hood.
I found 3 things during the work:

  • There are warnings in errors.go (form ErrFoo (ST1012))
  • The string type of the message argument are not quoted in function "String()". For better reading I think it should be.
  • For better reading in my opinion all "interface{}" should be replace with "any"

I can change/fix this on this PR. Or it is better to create a new issue?

You can use this, don't need create to new issue imo