CODEWITHSUNDEEP
rubylinuxapisockets
tarnfeld
tarnfeld

Reputation: 26556

Building a linux service in Ruby that other processes can interact with, maybe via a socket?

I'm looking into building a service to run in the background that allows clients to connect and send commands, and get data back. I'm planning on writing the service in Ruby (as a gem) but wanted to know what the best method would be to allow clients to connect to the API?

I figured a socket connection would make sense, like you'd connect with Redis or something, but I'm not sure where to start!

Any tips would be much appreciated :)

Upvotes: 1

Views: 269

Answers (4)

Sergio Tulentsev
Sergio Tulentsev

Reputation: 230336

I've built a couple of daemons with EventMachine in the past. It is efficient and powerful, supports TCP, HTTP and everything else. People even write web servers on top of it.

Upvotes: 0

Xaca Xulu
Xaca Xulu

Reputation: 659

I'm using a Ruby/Rails app with Redis running in the background on an EC2 server (Amazon Web Services AWS). This is the ubuntu build I found to be easiest to work with:

Linux version 2.6.32-341-ec2 (buildd@crested) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #42-Ubuntu SMP Tue Dec 6 14:56:13 UTC 2011

In my main .rb file that does most of the polling/searching I have this rubygems required, you should definitely check them out:

require 'aws'
require 'redis'
require 'timeout'
require 'json'

Let me know what you are specifically trying to do if that doesn't help you enough. Good luck!

Upvotes: 0

Daniel Pittman
Daniel Pittman

Reputation: 17182

Since you ask for any tips, my advice to you is that building a service container is hard work. Since you don't actually need to, there being lots of awesome service containers already, you should probably use one of those.

I would recommend something behind HTTP, which gives you a whole lot of advantages around existing tooling, message framing, content negotiation, scaling your service, and deployment and upgrade models.

If you want to avoid external dependencies, using something like Webrick or Mongel that is pure Ruby is a fine way to avoid needing to wrap Apache or Nginx around your system.

This also allows you to separate out the concerns in your project: work on building the actual service layer first, handling commands and returning responses. Run that under any web server, and get it going.

Then when you have time, focus separately on how to build the service container to meet your needs: because you know that the underlying service layer works fine, you can focus on only solving the container problems.

If you really do want to build your own container, I strongly recommend you use something higher level than a socket. Tools like 0mq provide framing and other message layer features that you don't get from a socket, and make it much easier to focus on defining the interesting parts of your problem space - the commands - rather than low level details like parsing a wire format and protocol.

Upvotes: 2

Thomas
Thomas

Reputation: 181745

Yep, you're on the right path. A socket is just a bidirectional communication channel that allows two programs to exchange bytes. If both endpoints are on the same machine, UNIX sockets are the obvious choice; otherwise, you'll need a TCP socket to communicate over the network. The principle is the same in either case.

On top of the socket, you'll have to define your own protocol, or you could use an existing one (such as HTTP) if it applies to your situation.

A random sockets tutorial.

Upvotes: 2

Related Questions