Golang QUIC support

[Trevor Schroeder]

Back in June, Brad Fitzpatrick commented that there were no Go QUIC implementations.

Is anyone aware of that having changed in the interim? For kicks I'm thinking about building a lightweight swigged interface to the chromium source.

[Jim Roskind]

There has been no mention of a Go implementation that I've heard of.

Be wary that although we're trying to not change things... we are now up to revision 13 (we bump the rev when we make an incompatible change... thought most versions can be "negotiated" at the cost of a round-trip).  

Bottom line: The protocol is still in flux as we attempt to correct issues, and flesh out other items.

Jim

On Mon, Jan 20, 2014 at 1:44 PM, Trevor Schroeder <tsch...@gmail.com> wrote:

Back in June, Brad Fitzpatrick commented that there were no Go QUIC implementations.

Is anyone aware of that having changed in the interim? For kicks I'm thinking about building a lightweight swigged interface to the chromium source.

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/groups/opt_out.

[Trevor Schroeder]

Yeah, that's actually one of the reasons I'm thinking of swigging the chromium source.

Not just faster delivery time but also to the degree that it remains a moving target that's the best public reference implementation I know of.

Thanks.

[Mario H]

Hi,

how is your progress?

Are you planning to create some kind of stand-alone QUIC library? Since, currently it is pretty much bundled with the Chromium sources..

Regards, Mario

[Trevor Schroeder]

Nothing to report to date.

I spent some time working with the chromium source, switching things to build as DSOs instead of static libraries, manually hacking swig builds, etc. The default build rules end up hiding all symbols in at least a few critical libs if the target is a .so. It's probably fairly easy to update the gyp rules to fix that, though I haven't actually tried since I haven't had a lot of free time since my first message to play with it.

My current thinking is that to start with it would be a patch set against the chromium source, though to be honest without even a working proof of concept it's probably a fairly distant concern. ;)

[Mario H]

Yes, I came across the same issue.

I put the following in my gyp file. (In your case it should be a fairly toplevel gyp file..)

       'conditions': [
         ['OS=="linux"', {
           'cflags!': [
             '-fvisibility=hidden',
           ],

           'cflags_cc!': [
                '-fvisibility=hidden',
              ],

           'cflags_cc': [
                '-fvisibility=hidden',
              ],

         },]
       ],

I don't think all three are necessary.. (And I'm pretty sure the last one is wrong.)

But anyway, it works. Compiling like this, all required symbols are there.

Hope this helps. ;-)

Best regards, Mario