We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Arrrr me hearty! Sailing the Seas of DRb in a Shoe

00:00

Formal Metadata

Title
Arrrr me hearty! Sailing the Seas of DRb in a Shoe
Title of Series
Number of Parts
50
Author
License
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language
Producer
Production PlaceMiami Beach, Florida

Content Metadata

Subject Area
Genre
Abstract
You insouciant scalawags will share the experience of a lifetime as you play a game built atop DRb and Shoes based generally upon the phenomenon known as Spaceteam! Except with Pirates!! Join us as we skirt the treacherous shoals of DRb, learning techniques that will allow you to navigate it like you were born on the high seas! Dig for the buried treasure of Rinda to discover the mysterious secrets of the RingProvider and TupleSpace! Storm the fortress of Shoes and learn about it’s secret trapdoors and avoid the dungeons! Team up with your fellow attendees to plunder the high seas and avoid the Curse of the Live Demo!
SpacetimeGame theoryCopyright infringementComputer animation
SpacetimeAndroid (robot)Game controllerGame theoryExecution unitMobile WeboutputCollaborationismWhiteboardComputer animation
Game theoryIndependence (probability theory)WhiteboardMultiplication signGame controllerSymbol tableVideo gameMassAsynchronous Transfer ModeRandomizationWordComputer animation
SpacetimeCartesian coordinate systemCopyright infringement
Peer-to-peerTelecommunicationDistribution (mathematics)CodePerfect groupProcess (computing)Server (computing)SoftwareService (economics)Perfect groupSoftware developerCodeDemosceneDistribution (mathematics)SpacetimeWeb 2.0Coma BerenicesQuicksortInformationMereologyRandomizationCommunications protocolComputer programmingTelecommunicationTupleBitComputer animation
Copyright infringementGame theoryContrast (vision)SpacetimeExpert systemComputer animation
Installation artCloningAliasingWritingJava remote method invocationLocal ringObject (grammar)Game theoryInformationCopyright infringementParameter (computer programming)Library (computing)Price indexServer (computing)MereologyProcess (computing)Greatest elementLine (geometry)Java remote method invocationComputer animation
Thread (computing)Shift operatorPeer-to-peerClient (computing)Line (geometry)Pointer (computer programming)Parameter (computer programming)Process (computing)Server (computing)Greatest elementEndliche ModelltheorieLink (knot theory)Computer programmingImplementationSpacetimeComputer animation
Data modelTupleComputer programmingEndliche ModelltheorieSpacetimeTupleData storage deviceMereologyLengthArray data structureImplementationTemplate (C++)Water vaporLibrary (computing)Computer animation
Template (C++)Military operationTupleWindows RegistryRing (mathematics)Server (computing)UnicastingverfahrenMultiplicationBroadcasting (networking)Ring (mathematics)TupleOperator (mathematics)Game theorySpacetimeBroadcasting (networking)Matching (graph theory)UnicastingverfahrenWrapper (data mining)Service (economics)CASE <Informatik>Copyright infringementFlow separationGroup actionProcess (computing)Message passingRange (statistics)Template (C++)Internet service providerVirtual machineTelecommunicationString (computer science)Multiplication signOcean currentTimestampComputer animation
Computing platformGraphical user interfaceFormal languageRewritingGame theorySoftware developerCross-platformGraphical user interfaceCopyright infringementComputer animation
Element (mathematics)outputEvent horizonObject (grammar)Type theoryDisplacement MappingClique-widthFlow separationGame theoryGroup actionGame theoryRevision controlMultiplication signMobile appTrailImplementationComplex (psychology)DataflowShape (magazine)Object (grammar)Variety (linguistics)Arc (geometry)TouchscreenForm (programming)Graph coloringStack (abstract data type)Line (geometry)Element (mathematics)Linear regressionMedical imagingFunctional (mathematics)CuboidQuicksortoutputBlock (periodic table)Regular graphField (computer science)BitFamilyCodeSoftware developerEvent horizonComputer clusterRight angleKey (cryptography)Analytic continuationSystem callLink (knot theory)Computer animation
Open sourceGame theoryGroup actionImage registrationSystem programmingClient (computing)TrailMessage passingCopyright infringementGame theoryOpen sourceThomas BayesGroup actionService (economics)MultiplicationPhysical systemClient (computing)CuboidElectric generatorCartesian coordinate systemImage registrationMessage passingWeb applicationComputer architectureSpacetimeFunctional (mathematics)ImplementationLogicWordEnterprise architectureOnline helpData managementQuicksortBroadcasting (networking)BitTuplePopulation densityElectronic mailing listComputer animation
Game theoryArchitectureDistribution (mathematics)Service (economics)Image registrationGroup actionDependent and independent variablesBridging (networking)Dynamic random-access memoryBlock (periodic table)Game theoryQuicksortGroup actionVariety (linguistics)Computer architectureImage registrationElectric generatorWindowDependent and independent variablesStatisticsSpacetimeTupleElectronic mailing listReading (process)TrailBlock (periodic table)TimestampFrequencySlide ruleService (economics)Message passingComplete metric spacePoint (geometry)MereologyCopyright infringementData structureCartesian coordinate systemRight angleConnectivity (graph theory)Process (computing)WordMultiplication signDiagramSoftware bugCountingCASE <Informatik>Ferry CorstenTable (information)LogicSoftware crackingClient (computing)Greatest elementComputer animation
DiagramArchitectureGame theoryLogicGroup actionSpacetimeClient (computing)TelecommunicationMobile appCartesian coordinate systemData structureWrapper (data mining)TupleBitInformationConnectivity (graph theory)Level (video gaming)Object (grammar)Computer animation
MereologyGame theoryServer (computing)Crash (computing)WordPairwise comparisonGame theoryCopyright infringementSoftwareMereologyInformation securityServer (computing)Client (computing)ResultantRing (mathematics)Point (geometry)1 (number)Computer animation
Game theoryBit rateGame theoryPoint (geometry)Service (economics)CASE <Informatik>SoftwareMobile appOrder (biology)Computer animation
Error messageMessage passingConnected spaceGame theoryOnline chatCopyright infringementGame theoryMalwareError messageGoodness of fitUniform boundedness principleKeyboard shortcutHookingComputer animation
Level (video gaming)Mechanism designGame theoryQuicksortSpacetimeMoment (mathematics)Level (video gaming)Endliche ModelltheorieMetropolitan area networkRight angleComputer animation
Game theoryOnline chatDemo (music)Group actionOverhead (computing)Level (video gaming)TouchscreenComputer animation
3COM <Marke>Online chatGame theoryInformation security2 (number)Copyright infringementUniform boundedness principleBitInformation securityVirtual machineUsabilityRemote procedure callComputer animation
Client (computing)Information securityInstallable File SystemAddress spaceRange (statistics)Information privacyElectronic mailing listPublic key certificateProcess (computing)BefehlsprozessorLimit (category theory)Computer networkFile systemProcess (computing)Physical systemCodeLimit (category theory)Computer programmingNetwork socketServer (computing)Service (economics)Gastropod shellPublic key certificateLevel (video gaming)Range (statistics)Virtual machineObject (grammar)Socket-SchnittstelleContent (media)Data managementIP addressSoftwareSystem callGame controllerString (computer science)Cloud computingLocal ringElectronic mailing listGame theoryProof theoryCopyright infringementMessage passingInjektivitätInstance (computer science)Computer fileInformation securityThread (computing)Integrated development environmentAddress spaceCellular automatonInformation privacyPeer-to-peerGraph coloringComputer animation
Message passingResource allocationDigital filterLoop (music)Exception handlingFunction (mathematics)StatisticsSystem callComputer programmingCore dumpMessage passingResource allocationStandard deviationDefault (computer science)Exception handling1 (number)ResultantLetterpress printingDirect numerical simulationCartesian coordinate systemRoutingPoint (geometry)Error messageFunction (mathematics)Row (database)Dependent and independent variablesConnected spaceArmSoftwareOrder (biology)Game theoryAddress spaceLoop (music)Object (grammar)CASE <Informatik>StatisticsMultiplication signParameter (computer programming)Interface (computing)Slide ruleArrow of timeRootTimestampSystem callCopyright infringementComputer animation
RAIDPatch (Unix)Error messageDisintegrationGame theorySoftware developerGame theoryAdditionGroup actionSpacetimeMobile appGame controllerRAIDCopyright infringementError messageCartesian coordinate systemPatch (Unix)Different (Kate Ryan album)Electric generatorMetropolitan area networkPoint (geometry)Computer animation
Demo (music)Electronic visual displayRing (mathematics)Server (computing)Computer animation
String (computer science)Execution unitRing (mathematics)Core dumpMessage passingCopyright infringementGame theoryComputer animation
Game theoryMenu (computing)Demo (music)outputTouchscreenOverlay-NetzGame theoryElement (mathematics)Regular graphComputer animation
Demo (music)Game theoryGame theoryTouchscreenDemo (music)Computer animation
Demo (music)Metropolitan area networkRevision controlRow (database)Data storage deviceBit rateSelf-organizationCompass (drafting)Computer animation
Demo (music)Game theoryMaß <Mathematik>Inclusion mapTouchscreenGroup actionLevel (video gaming)Game theoryStatisticsMultiplication signHeegaard splittingCore dumpBitComputer animation
SoftwareGame theoryCore dumpInformationStatisticsBitGroup actionDemo (music)FeedbackComputer animation
Transcript: English(auto-generated)
Hey everyone we're ready? Ready for some pirate game?
Arrrr! I am Davie Stevenson, I work at the Esri Portland R&D Center in Portland, Oregon. I am Eric Hodel, I work for AT&T under Coby who is doing the filming here. I am Rain Hendricks, I also work for Coby at AT&T and I am responsible for looking like a pirate and saying argh a lot.
Arrrr! So who here has played Space Team or know what Space Team is? Excellent! We've got at least like a third of you who kind of know what's coming and the rest of you are in for a treat. Let's see if the sound here works.
Maybe. This is the Space Team trailer? Sound? Sound? There is sound. No sound. Anyway. So Space Team is a co-located collaborative mobile game on iOS and Android.
Where you work together as a space team. So everyone gets a randomly generated board indicating your spaceship controls. And you get a command that you are responsible for making sure it gets activated.
However that command is not necessarily on your board. You also have to avoid asteroids and wormholes. And there is other technical difficulties like all your controls turning into crazy symbols.
Or falling apart. Or there is goo and random other things that can ruin your life. There is also a massive player mode which I actually didn't know about until watching this trailer.
Anyway it's gotten lots of awards and it's a lot of fun to play. So Eric and I like writing DRB and so when we were trying to figure out a good topic for a talk about it. We decided well what if we re-implemented Space Team but used Ruby to do it?
What if we used DRB and Rinda to do the distributed performance? And why not use shoes to write the GUI application? And then we decided well space, that's passé. Let's do it with pirates.
So we chose to use DRB because it easily allows us to communicate between multiple processes. Where you are either on the same machine or across a network. And you are both able to get and send data really easily. It's really transparent and it's peer to peer so you don't need one server or any of that.
You just go and connect to each other. We use Rinda because it allows us to flexibly discover the other services. So you don't have to have any explicit destination. You can just put it in this, it includes a tuple space. You can just put it in the tuple space. Put information in the tuple space, get it out super easy.
We chose shoes because Davy is going to explain. So a lot of people have asked me why didn't you just write a web server and do it that way? And one is that HTTP is already sort of a distributed protocol.
Trying to do things with DRB and Rinda behind the scenes. It's not quite as obvious that something awesome is happening. Because we all for the most part have done web programming before. And spinning up a server somewhere far away, that's easy to handle a lot of that background processing. Not only that, but this is RubyConf, not RailsConf, or web programming with RubyConf.
So we really wanted to put a talk together that had nothing to do with web programming at all. So shoes. Shoes is a really great resource that the Ruby community has. But it needs a little bit of love and attention. For us it was a perfect showcase for distributed code because it itself has no communication built in at all.
Shoes is also, you know, I think, finding some great examples of really cool things you can do for shoes and trying to get people a little bit more involved in the development was another really big plus for me personally.
So you might all be wondering why pirates? And as the resident pirate expert beard, I'm going to tell you there are two reasons why pirates. One, because this is a Ruby conference and pirates like treasure. Nothing. And two, because pirates are clearly better than space teams.
Clearly more exciting to be a pirate. And that's it. No, that's it. Also, yarr. I'm contractually obligated to say yarr. Okay, so I tweeted this out yesterday, tweeted it out last night really late, other people retweeted it out this morning,
but just to make sure, if you want to play this game, you need to have followed the preparation instructions, you have to install JRuby, install shoes. And we'll get back to that, there's also all this information which is now in the pirate game GitHub repo, so if you want to look there, you can find it, all the preparation instructions.
So, DRB is a remote method invocation library for Ruby, so it allows you to use remote methods as if they were local and call them the same way you would call local methods. It's part of the standard library, and you can load it with require DRB.
And so here we have an example of a shared array over DRB. On the first line we create our array, and then we go and share it, and we put nil in that first argument so that DRB can pick which URI, so we display that, and then at the bottom here we wait for you to quit the server.
And so in the client we just go ahead and reference it with that URL that we printed out, we can go and append an A or push a B or a C on there. And then in the third process we can go and get that reference again, and then if we go and print out what's in the array, it goes to the server and it can see all the stuff we've added to it.
And Rinda is an implementation of the Linda tuple space model of distributed programming, there's a book on this, but I forgot to include the link, so ask me later. And it's also part of the standard library, you can load it up with Rinda slash tuple space, and it stores tuples or kind of like arrays of arbitrary length of data.
So you can write a tuple into the space and then read or take tuples out of the space with templates, and they're what Linda calls an anti-tuple. And so this is an example we use in Pirate Game. So there's several operations, there's read and write and take.
And so with the take here we go in with this template, so the first thing it must be a button and the second thing must be a string, but the third thing it's a range, so it uses the case equals operator to match that. And then the last one is nil, it can be anything you want. And so that'll just wait until a tuple appears in the space that matches it,
and then you'll get that tuple back out. And so this is waiting for the user to press the keel button, so when the user presses that on possibly another machine, it'll go and write this tuple in with the current timestamp, and so if those match up, you press the keel button at the right time, then that take goes and returns and then it can register the action that you've pressed.
And then on top of the tuple space, Rinda provides service discovery through the Rinda ring library, and so it has coordinates between processes using broadcast or unicast UDP messages with multicast support coming in Ruby 2.1,
and it holds the tuple space used for all the communications. And then there's also the ring provider, which is a wrapper for advertising your service into the tuple space. So Shoes was originally created by Y to be a very simple cross-platform GUI toolkit for the Ruby language.
There has been a couple of rewrites since then, the current is Shoes 4 is an all Ruby rewrite. It is still under active development, so if you go look at the preparation instructions, you'll notice that I require you to check out a very specific commit of Shoes 4, mainly because people have been doing a lot of awesome work in the month of October,
and we were not able to keep up and make sure that Pirate Game works with all the cool new stuff that has been added. We're going to be working on that in the future, hopefully. So there's a Shoes manual online, which has been for the previous Shoes versions,
so you can read a lot more about a lot of the things that are provided by Shoes. There's basic layout, so how do things layout on the screen, do they stack, do they flow. There's a variety of input elements that are provided, buttons, radio and checkboxes, text fields, things like that.
You're able to draw directly on the screen, you can do background images, colors, you can draw shapes, arcs, various other shapes, add images, and you're able to animate, move, and have events. You can do key events or other things like that, hover.
And so there's a link to the manual if you want to check that out a little bit more in depth. So the currently Shoes 4 definitely has still some functionality gap from the previous Shoes implementations. And like I said before, a lot of this might be already out of date
because I know that they've been adding a lot of these features lately. But for our implementation we had to kind of get around some of the deficiencies, lack of features that we're in Shoes 4 right now. So not all the movement methods have been fully implemented on all the objects. You can move things but not displace, which is always fun.
Some of the width-height accessors and setters weren't working very well. And the other thing that was kind of rough for us was that the general show, hide, and toggle actions on all the objects didn't exist so we had to kind of basically destroy and rebuild things a lot. But hopefully that will be going away soon.
The other thing that kind of took us a little while to figure out, so I figured I would state it for all of you, was that the animations run in parallel and you do need to manually manage them. So unlike a lot of the other sorts of things when you clear off the screen, it does not clear out the animations like you might expect it would.
You need to explicitly call start, stop, remove methods on those animation blocks. So there was a fun time when I was like, why is the app just getting slower and slower as I move the screens? Because I was basically stacking animations upon themselves over and over and over again and losing references to them and not clearing them up.
So, protip, you need to keep track of your animations and for us it was really helpful to separate out the drawing from the animation steps. So that really helped clean up our code a lot. The other thing that we found by developing this, for what I can tell for Shoes is a pretty complex shoes app,
was that it can highlight a lot of the regressions that might be introduced as Shoes 4 development continues. And so hopefully we're going to be using that to use the game to detect those issues and be able to fix them and contribute back to Shoes. I know I already have a couple patches that I want to contribute, so hopefully that can be a really great benefit for having something like this around to test on regularly.
So, all this is open source and we have three gems. They're under Davies Repo as pirate command, shuttlecraft, and pirate game. So in the grand tradition of noun that verb and action that thing generators,
we present you the pirate themed generator, which has a corpus provided entirely by Davies that includes the word booty, which is going to cause us some problems later, I expect.
But you are free to use this. It is free as in Grog for all of you to enjoy. So please add some more pirate themed awesomeness to your web applications and enterprise applications. I think it would be great.
Shuttlecraft was built to basically add an extra layer of stuff upon the sort of distributed system stuff that's provided by Rinda. It explicitly helps simplify a lot of the registration and client services management. You know, with Rinda it's kind of, you get a full tuple space,
but you are kind of left to implement everything on top of that. So with the shuttlecraft you're very easily able to create a mother ship that handles managing the tuple space and watching for registrations, and then multiple shuttlecrafts can dynamically find any mother ships around and register very easily.
And then both sides can easily get all the lists of registered services. We also added a bunch of convenience methods to help broadcast messages from either side as well. And hopefully we'll be adding to that sort of functionality, make it a little bit easier to use Rinda since it is a little bit dense.
And then of course there's Pirate Game, which you use to play the pirate game. So this is kind of a, perhaps a traditional game architecture, where you have sort of a game master that handles all of the business logic,
and it explicitly issues commands to all the games and manages the actions coming back from that. But that is no fun at all. And so by using Rinda and DRB we're able to implement a variety of other game architectures.
So I'll talk about three of sort of the subcomponents of the Pirate Game. The registration, layout generation, and the more complicated, issuing the action and gathering responses and saving those actions as completed. So yay diagrams, because there's not space on all the slides for all the words,
we'll be color coding the components like so. So for registration, and this is sort of the stuff that's baked in directly to the Shuttlecraft gem. So each of the games simply, when it tries to register with the game,
it just writes a name into the tuple space. And then the game master can use the read all to collect those names. So these names will live in the tuple space as long as those services are registered.
And in that way the game master, and also the games themselves, can know who else is around. And so that URI there, that's the DRB URI that can be used to directly communicate to any of those processes. And then when the games exit, then they take those names out of the tuple space to indicate that they are not registered anymore.
So for the layout generation, this is in our game, the issuing what buttons should appear on each of the games. For right now, the simplest way was to generate a list of all the buttons that should be scattered amongst all the different games, and each game gets that full list.
And then it also gets a smaller list of the buttons that should be displayed on that particular game for that stage. And for this we just simply use direct DRB. There's no real need to use Rinda in this case, since we know exactly who we're talking to at this point.
So now we get to the fun part where those actions are being generated on each of the games. And so the architecture that we took was that each of the games was going to be responsible for generating that action and then waiting for the message from the other games to indicate that that button has been clicked.
The game master is responsible for gathering up all the list of correctly completed actions. And so here we simply are running a take that will watch for the completed action tuples as they're entered into the tuple space.
And so this will block until a matching tuple is entered. So the game generates an action, haul the keel. Then it also sets up a take which blocks and waits for the button click from the other game.
So the other game has clicked the button and writes a tuple into the tuple space, which is similar to the previous slide. Here is the button action, the button that was actually clicked, which was keel, the timestamp that it was clicked, and the URI that actually clicked it.
So who is this from? And so the timestamp is really important to be able to detect whether or not the button was clicked within the correct time period. If it's too late, then the other game will not register that as a correct action. And the from we use basically just for tracking. We want to be able to indicate statistics on the end about how many people have,
you know, who's correctly performed how many actions. So now that that button has been put into the tuple space, that's going to match that take that the previous game is blocking on. And so it takes that tuple out and then writes a new one in, an action tuple, again with the keel and passing through that timestamp and from URI
to indicate that that action was completed successfully. And that, of course, matches the take that the game master is looking for. And so it grabs that action, increments it, marks, you know, as another completed action in the total count,
and we all move on. So I'd also like to discuss a little bit of our kind of like internal structure of the application. So we split up into kind of three main components. The apps, the master app and the client app at the bottom, those are basically the shoes apps themselves.
But the vast majority of the logic is not in the shoes app. That's in the game master and client objects, which are wrappers for the shuttlecraft gems. So the apps themselves are responsible only for layout, animation and drawing.
Pretty much any game logic is not in the main shoes app itself. It's in the sub-object. So the game master knows how to generate stages, collect information about the actions, et cetera, et cetera. And the client knows how to automatically generate the actions and watch for the button clicks and all that fun stuff. And then the shuttlecraft gem handles all the communication through the tuple space.
You landlubbers and scallywags, prepare yourselves for the pirate game. That's all I got.
Okay, so preparation again. JRuby shoes 4. And now the next important step, which is to install the pirate game gem. So a brief discussion about networking. Do you want to take this one? So theoretically this should all work on the conference wifi,
but for best results you want to be using a personal access point or a private network. Also for reasons of security, which we'll be covering later in the talk. So to run the game, someone needs to run the ring server. We haven't made this automatic as part of the game master yet.
You only need to run one. And if you run more than one, you may have some problems. So try not to do that. And we're working to get this easier to use. And you also need only one game master. But if you have multiple, the client will show all the different ones. So if your friends don't like you very much,
maybe they'll create their own and then they'll leave you alone. And that would be sad. Also, if the game master crashes, the game is stranded. We had it working for a while and then we broke it. So you'll have to just restart the client. So pirate game. It is for one to four players.
So you can in fact play the game all by yourself. It's totally a feature and not a bug. So the first step of course is to enter your name. Then you need to find your game. So this is where the game masters are found by the Rinda Service Discovery. And you will see any of the games that are visible to Rinda at that point.
So if you're on a conference Wi-Fi, that might be a lot. If you're on a personal access point, that would probably be only one. And you can always hit the rescan button, which will scan the network again in case another game master has popped up. So it doesn't really matter in what order these apps are launched.
So one issue or basically a feature that hasn't been developed yet, which is if the join fails, so if you try and join a game that already has four players or a game that's already started, you will not receive a very good error message. And instead will enter an empty, disconnected pirate pub all alone with no one to chat to.
And no grok. But if you do successfully connect, you'll be taken to the pirate pub. And so you can see there that if you're registered or not, if you're unregistered with the game master, it will say not registered and have a little register button. And here, in the pirate pub, you can chat with all your fellow pirates and discuss fun things.
And yes, you do have to click the send button. It's really difficult. All of us are used to hitting enter and having it work, but have not figured out how to hook up the key bindings for that correctly, if there even are any. So if anyone knows, let me know.
So at this moment, the game master also needs to trigger each stage. In the future, we'd like to switch over to the sort of space team model, where each player gets to indicate whether they're ready to proceed or not. But that just hasn't happened quite yet.
So then, as you enter each stage, you need to work together to keep the ship afloat, man the ship, keep it headed in the right direction, and beware of bad weather. So this is a quick little demo. So yeah, we've got the chat here. Why is the rum gone?
I'm over-clicking the start button. So here's the stage. There's your action, torture the crow's nest. You've got to find the button. It's really hard because it's windy on this screen. So the buttons are really flying around. It's random, we're sorry.
Yeah, I clicked the wrong button there because it's hard. And then when you're all done clicking the musket buttons, it'll take you back to the pirate pub here in a second. So you can ask why the rum is gone again.
It is a little bit more exciting when you're playing with more than one person, I promise. No, there's no shouting. There's very little shouting when you're playing by yourself. So security. DRB doesn't give security a very high priority. It's more focused on ease of use and transparency.
There are some security features though. So the biggest problem is DRB gives you full access to the remote machine. Anything the server can do for itself, you can do on the server. So that means if you can system RMRF on the server, you can do it locally.
So instance eval and all those things are all very dangerous methods. So you've got to be careful about who you use DRB services with. And I've written a proof of concept of how to infect another DRB machine with code from the local machine called the DRB-Worm.
It's a gem you can see there. It doesn't do anything dangerous now, and I don't expect it ever to do anything dangerous. But this is just so you can look and see what kind of stuff that you can do. So at the message level, DRB has two methods of security. So you can add methods to this insecure method array.
But it's going to be very difficult for you to weed out all of the not dangerous methods because it's an opt-out, not an opt-in to good methods. You can also set the safe level for the thread that the DRB server evaluates the methods in.
However, that relies on tainting, and not every object gets tainted properly when it's sent over. So it's possible that you can get a non-tainted string with user local content in it even under a higher safe level where things like eval would be disabled.
So if you don't need network access for your server, you can run DRB over Unix socket. So that's just restricted to the one host, and you can use the file system permissions to control your access. And since you have no network access, you don't have to worry about other people being able to inject new content or inject bad methods. If you're running on a network, you can use an access control list.
It's like all of the other access control lists allow and deny by IP address or IP address range. But this can be difficult to manage, like if you're in a cloud computing environment, then your IPs are going to be changing all the time, and there's not really any data privacy. So if you have something secret that you want to send, you probably don't want to use this.
And there's also DRB over SSL using X.509 certificates where you have full privacy, but it's also you have to do certificate management the same way you have to do with updating your ACLs. You can also use Troot either through the system call or if you can set up a sandbox using the shell
so that way the program can't break out of it and write bad files. So if somebody goes and attacks your process, that means they can only consume CPU or create a bunch of processes. They can't do other bad things, or at least not file system level bad things. Unfortunately, JRuby does not support Troot, which this choose requires, so this is not super useful for the pirate game.
And in general, the best practices are always be sure you're talking to trusted peers. Make sure that all the hosts that you're going to communicate with don't have other processes that other users control so they can elevate their privileges, limit the accessibility, use Unix sockets if you don't need network,
use ACLs or SSL instead of just straight up TCP sockets. And of course, always run on a private network if you're not very trusting. So there's also a tool that I wrote to help you debug or monitor or understand how your program is using DRB not working
called DRBDump, and it works a lot like TCPdump. It monitors message sends and message latency and how many allocations it takes for messages to send and also shows you a log of all the messages that are scrolling by. It doesn't implement everything, it doesn't understand out of order TCP or MDNS, except that's going to be fixed in Ruby 2.1.
And there's also no filtering yet, and I think IPv6 support is currently broken. So you can run it as root like this, DRBDump, and it'll just be like TCPdump and it'll show you all the messages going by.
You can say, give me a summary of these 10,000 messages, so it'll just record, won't print anything, and at the end it'll dump the statistics, and then by default it listens on your default interface and the loopback interface, so you can just restrict it to loopback if you don't care about outside of the network stuff.
And these slides were supposed to be skipped, but I'll run through them. So this is the output of a message send, you've got the timestamp there at the top, the message sending address, this arrow says it's going out, it's message send, the message receipt address, and the message name and the arguments are last.
For message receipt, you've got the timestamp again, and this is the message sender, unlike TCPdump, this is who sent the message, but it's flipped from TCPdump, so the person who sent it is always going to be on the left. And of course the arrow goes the other way, who the receipt is coming from, and the status, and the response object,
in this case it's just a true because we asked for a respond to. And for an exception, you've got a broken arrow and it says exception with an error message. These are all easier to match, so you can just line them up and kind of see what's going on, so the ports are lined up on each side, so you can tell that the messages are from different connections.
And then it also collects statistics output, so you can see how many messages were sent, and packets and so forth, and how many allocations were required to send that message, and then also the latencies per peer and per message.
And the basic ones are just packets and messages and results and exceptions, and they've got min, max, average, and standard deviation for both. And so we use this in drbdump to fix, or use this with Pirate Game to fix some problems like a bunch of message spam, and then it's kind of reappeared again, so when we run the game you'll be able to
see how it's just kind of spitting out tons of messages that you shouldn't need to do. You can also use it to find hanging calls if you're like, okay, I went and sent this message and nothing's happening. Where did it get to? And also to verify that it's working how you expect. So, future. Do you want to pitch in? There's a lot of additional development
that could be added to Pirate Game to make it more fun, more full-featured. You know, we wanted to try and implement something like the asteroid or wormhole group activities that Space Team provides, something like maybe raiding a ship or surrounding a hurricane. It would also be fun to add some extra special controls instead of just having buttons everywhere,
like being able to steer the ship with a wheel or other things like that. Also thought it would be fun to be able to build in some character generation, like with the Space Team, they make an automatic little alien man for you. You can make an automatic little pirate with randomly selected beard, parrot, eye patch, maybe different hair.
There's also a lot of infrastructure improvement that can be added to the game. It would be nice to completely eliminate the need for an external Game Master app to integrate that directly into the Pirate Game itself so you can launch that internally. Of course, always better error handling, and I'd also like to make it so that it was easy to restart a game.
At this point, after the game has ended, you have to restart all of the applications to play a second game. So, play, contribute, hopefully you enjoyed it, and we're going to try and run a live demo.
We'll see how well that works. So, I am running the ring server. Is that not working? It's mirroring some displays.
Everything is really small. So, this tab is running a ring server, and we're running DRB dump in the background as well, so you can see a lot of the DRB messages flying by already.
So, run the Game Master, run the Pirate Game, start of the game,
the screen is the Foggy screen. This is actually another interesting thing about Shoes, is that you cannot actually overlay anything directly over the input elements. So, you can see that the launch button here is still crystal clear,
which doesn't really make the Foggy actually that much harder than the regular thing, but whatever. Okay, so, here we got... So, Eric's already joined. Here I'm on the Choose Game screen, I can see my demo, so I can join.
Anyone else want to join? Can't get on the network, so, ah yeah. Okay, so, like I said, the Game Master, you have the start button, it's go time.
Vandalize the treasure. Swab the rum. Rum. Compass. Attack the compass. More compass. Confiscate the ocean. Steal the gunpowder. Assault the chest.
Pop the compass. Rum. Compass. Who is the poop deck? Attack the chest. I'm not raising it. Okay, abandon the gunpowder. Explore the pistol. Okay. Yes, success.
And so, at the end, on the Game Master, you can see some statistics. So, it still displays the four players that have joined. This was stage one, it was a success. We completed 11 total actions, and this is the split out by the DRB URI.
And then, this is the game run down so far, which, since we only played one stage, is exactly identical. And, I think if we start but don't play, and it's going crazy back there. If we don't play and we let it fail, then you'll see the end screen.
And so here, you can also see on the Game Master, as it's running, the live actions. So, we're on stage two, no actions have been performed, we have the time left. And this is, it's windy. So, that's what windy looks like. It's a little bit harder, it's actually surprisingly more difficult.
And so, here's a little, so here you can see the DRB dump. So, this is the information that's kind of flowing through. You can see that it's, the Game Master is reporting back the end of game stats, because we failed the game. And here, we get a little bit of information feedback.
I want to make this a lot better as well. So, I know that out of the total actions, my contribution was six of them. But yeah, there's lots of room for improvement there. So anyway, demo successful. Please get everything installed, try and play it. The hallway around, it's quite fun.
And yeah, let me know what you think. Contribute. I hope you enjoyed it.