Question: how/where to save URI parsed during Upgrader.Upgrade() ? about ws HOT 3 CLOSED

Hi @JordanP,

Thank you for your feedback on article =)

So, there are few ways you could save the GET parameters from URI. It depends on the performance requirements to your application. If the memory consumption is not the main problem, then you can use net/http server and ws.UpgradeHTTP() function, instead of ws.Upgrade():

http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
    conn, brw, hs, err := ws.UpgradeHTTP(r, w, nil)
    if err != nil {
        // handle err
    }
    // save r.URL.Query()["user-name"]
})

Note that ws.Upgrade provides way to use so-called zero-copy upgrade. It does not allocates any data to fill structs like http.Request and so on. It is useful for high-load applications, which are required to be as much efficient as possible. There is ws.Upgrader struct (which default instance is used by ws.Upgrade) which allows to copy any data by your self:

var userName string
hs, err := (ws.Upgrader{
    OnRequest: func(host, uri []byte) (err error, code int) {
        // Parse query from uri somehow. 
        // For example (not most efficient), with use of net/url.ParseQuery().
        // Store the appropriate value to the userName variable.
        // If some error occur, return it and corresponding HTTP status code.
        return nil, 0
    },
}).Upgrade(conn)

That is, ws.Upgrader is used to avoid allocations that will not be used by a particular app. Filling some structs inside in generic way will cancel the idea of zero-copy. That's why there are callbacks in ws.Upgrader for: to give you ability to implement your own logic of copying data without redundancy.

Cheers =)

from ws.

Thanks for your detailed answer. Memory requirement is a bit of an issue to me, my app is currently handling around 700k concurrent WS session (with gorilla/websocket), not the 3M you have at mail.ru but still :)

I like the second example, I am kinda new to Go, but I understand that the function passed to OnRequest would be a closure given that it uses/captures the userName variable defined in the outer scope. In this example, would a new Upgrader struct by initialized for each and every new WS session ? Once compiled, is this efficient, i.e could the compiler do some speed magic ?

from ws.

Yes, 700K is a huge amount =)
Yes, Upgrader will be initialized for every accept operation, but struct itself will be allocated on stack, thus such initialization will cheap. The captured variables will escape to heap, but it is seems ok when you want store copied data outside the accept operation function.

from ws.