For my current client we’ve had a request in to enable video Hangouts. The first attempt was to run the traffic through the on-premise McAfee Web Gateways that are used to inspect all traffic in and out of the Internet. Performance wasn’t great and on looking closer we could see that all traffic was TCP based. In consultation with the supplier the conclusion was that the MWG can only process TCP traffic as it’s a stateful engine. We knew we needed to be using UDP to get the performance we needed as this was a video stream.
We reconfigured a single office to route the Google netblock of addresses directly to the perimeter firewalls and then conducted an experiment to see what happened. The pilot user population reported great performance. This was a bit of a surprise as we had expected to do DNS changes to allow the Chrome Hangout functionality (which was previously a discrete plug-in) to resolve the video servers. By default all our browser clients hand off all Internet access to the MWG’s including DNS resolution.
In consultation with some Google deployment specialists we believe that the following is happening:
1. Both users start their Chrome browser which immediately establishes a TCP connection to Google through the MWG’s
2. One user calls the other using Hangouts, the session initiation is established over the existing TCP connection to Google
3. Each client initiates UDP traffic to Google using the subset of Google netblock IP addresses returned in the session initiation
4. Video commences
The key points to note are that the Hangouts video functionality didn’t need to resolve the IP address hence we didn’t have to expose Internet name resolution into the internal DNS. The Hangouts functionality is not proxy aware – the UDP traffic was routed by default, enabled by the office router change directing Google traffic to the perimeter firewalls. My belief is that the Hangouts functionality tries to route out to Google before falling back to other protocols (and potentially discovering the MWG’s).
There is discussion out on the Internet about full cone NAT firewalls and the like. Our perimeter firewalls (without divulging suppliers) do NATing and are smart enough to allow inbound UDP traffic to be received and routed to the client that sent out UDP traffic to Google even though the traffic from Google is essentially unsolicited. I guess that makes them full cone.
Posted in Uncategorized
I’ve been having a lot of UI slowness problems with my 1st generation Nexus 7. I’ve seen a lot of people reporting the same symptoms online. Luckily I stumbled across this post online which seems to have done a lot of good:
Credit to the Blinkbox help site for this. I just purchased a Chromecast to link up with my Nexus 7 running 4.4.4. Annoyingly when I tried to cast a YouTube video I got an error occurred message. Fruitless reboots and power-off’s later I eventually stumbled across the solution – my BT HomeHub 5 has a Smart Setup enabled by default under Advanced Settings | Home Network | Smart Setup. Turn this off and it all worked.
This altered by understanding of the Chromecast devices, I had assumed it was a pure TCP/UDP transmission of the video across the local network. The implication is that the Nexus is acting as a remote control device similar to the DLNA device types and the Chromecast is streaming the content from the Internet itself.
It’s still annoying that individual apps have to be Chromecast enabled, the is a mirror screen option but it looks like my first generation Nexus 7 doesn’t support it even thought it’s present under Settings | Display.
So there I was assuming the display could be remoted using native X11 capabilities and it turns out xbmc on the pi uses opengl for embedded systems – gles. This means the app runs locally with no inbuilt way to remote the display. The solution is to run vnc, on the latest builds it’s part of the distribution so just needs an initctl start vnc and then use the glvncviewer on Ubuntu. 😊
Well I never knew that:
Using pipes take me back to my decade of Unix.
I realised back in May last year that the Cisco CCNA certification was to be revised on September 2013. So I spent July and August hitting a couple of books I had bought previously and going over an accelerated CCNA course I took in 2011. Luckily I passed first time.
The point of this post is that it reminded me that me actually studying a subject for a certification is very different to reading a technical book or looking at blog posts. While hard work, it does provide a lot of technical context and capability when talking to my network colleagues at work.
It had been years since I’d done a certification exam. I may now even be inspired to study for the CCNA Wireless.
When snowboarding I’m one of those paranoid types who likes to know their kit is always secure and tight. That’s just my mential abberation, this attitude was enforced on a Canada backcountry trip when a screw came off my bindings which could have left me stuffed on top of a mountain with only 1 foot able to be bound (since then I always carry ties and tape).
However, on the annual trip – some days boarding with the guys seemed better than others. I always put this down to my usual skills dip on the middle of the week i.e. the first 2 days start of excellently, I dip for the next 2 and get frustrated at myself then the last 2 it all starts to come good again.
After some self-examination, it turns out that after the first couple of days I used to pull the boot laces really tight, the just make sure the mental itch to be tight and secure is scratched. Then my performance would dip. When my boots are too tight I don’t get the soft ankle movemovement (no heel lift) that my boarding style requires. It’s all too stiff and I feel uncomfortable.
This year I slackened off the laces and I didn’t have the mid week dip!
My thinking is that the first couple of days my mental attitude doesn’t focus on my kit just my joy at being there. This gives me a really sweet riding experience. At that point I don’t know to pull my boot laces really tight. My goal next year is to make sure I don’t pull them too tight again.