

So: develop on insecure endpoints, deploy to production after you’ve debugged, and with secure endpoints. If you try to observe the traffic over secure connections, you can’t see what’s being sent and received. The techniques we’re about to talk about here will be really valuable for debugging cloud queue implementations, but they’re predicated on observing traffic over insecure HTTP.

But if we can arrive at the right settings, Wireshark is a fantastic tool for looking at cloud queue traffic. Wireshark is a robust app, but with that extensive capability comes some complexity, at least for those of us who aren’t networking savants. And even then, it’s difficult to display all logged data in a way that’s easily digestible. Now, you could build all kinds of logging in to your server (you should probably be doing that anyway!), but it’s often a very iterative, time consuming process to arrive at exactly what kind of logging you need. The first step to seeing what’s going on is to understand what the player is asking for from the cloud queue server, and what the server is telling it. You fire up the cloud queue (CQ) server, point loadCloudQueue at it, and… nothing. You’ve got your contexts and queue versions all set up. You’ve read our documentation and built a fantastic cloud queue implementation.
