# \[ANN\] Packet : A Pure Ruby Library for Event Driven Network Programming

**URL:** <https://rubytalk.org/t/ann-packet-a-pure-ruby-library-for-event-driven-network-programming/42381>\
**Category:** ruby-talk\
**Created:** [20 November 2007 19:14 UTC](https://rubytalk.org/t/ann-packet-a-pure-ruby-library-for-event-driven-network-programming/42381 "2007-11-20T19:14:45Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![Hemant\_Kumar](https://avatars.discourse-cdn.com/v4/letter/h/46a35a/32.png) [@Hemant\_Kumar](https://rubytalk.org/u/Hemant_Kumar)\
**Post date:** [20 November 2007 19:14 UTC](https://rubytalk.org/t/ann-packet-a-pure-ruby-library-for-event-driven-network-programming/42381/1 "2007-11-20T19:14:45Z")

</div>

Hi Folks,

I am pleased to announce "Packet", A pure ruby library for Event  
Driven Network Programming.

Packet is a pure ruby library for writing network applications in Ruby.  
It follows Evented Model of network programming and implements almost all the  
features provided by EventMachine.

It also provides real easy to user UNIX workers for concurrent programming.

Its best to have some examples going:

== Examples  
=== A Simple Echo Server:  
require "rubygems"  
require "packet"

class Foo  
&nbsp;&nbsp;def receive\_data p\_data  
&nbsp;&nbsp;&nbsp;&nbsp;send\_data(p\_data)  
&nbsp;&nbsp;end

&nbsp;&nbsp;def post\_init  
&nbsp;&nbsp;&nbsp;&nbsp;puts "Client connected"  
&nbsp;&nbsp;end

&nbsp;&nbsp;def connection\_completed  
&nbsp;&nbsp;&nbsp;&nbsp;puts "Whoa man"  
&nbsp;&nbsp;end

&nbsp;&nbsp;def unbind  
&nbsp;&nbsp;&nbsp;&nbsp;puts "Client Disconnected"  
&nbsp;&nbsp;end  
end

Packet::Reactor.run do |t\_reactor|  
&nbsp;&nbsp;t\_reactor.start\_server("localhost",11006,Foo)  
end

Those new to network programming with events and callbacks, will note that,  
each time a new client connects an instance of class Foo is instantiated.  
When client writes some data to the socket, receive\_data method is invoked.

Although Packet implements an API similar to EventMachine, but it differs  
slightly because of the fact that, for a packet app, there can be more than one  
reactor loop running and hence, we don't use Packet.start\_server(...).

=== A Simple Http Client  
class WikiHandler  
&nbsp;&nbsp;def receive\_data p\_data  
&nbsp;&nbsp;&nbsp;&nbsp;p p\_data  
&nbsp;&nbsp;end

&nbsp;&nbsp;def post\_init  
&nbsp;&nbsp;end

&nbsp;&nbsp;def unbind  
&nbsp;&nbsp;end

&nbsp;&nbsp;def connection\_completed  
&nbsp;&nbsp;&nbsp;&nbsp;send\_data("GET / \r\n")  
&nbsp;&nbsp;end  
end

Packet::Reactor.run do |t\_reactor|  
&nbsp;&nbsp;t\_reactor.connect("[en.wikipedia.org](http://en.wikipedia.org)",80,WikiHandler)  
end

=== Using Callbacks and Deferables  
Documentation to come.

=== Using Workers  
&nbsp;&nbsp;Packet enables you to write simple workers, which will run in  
&nbsp;&nbsp;different process and gives you nice  
&nbsp;&nbsp;evented handle for concurrent execution of various tasks.

&nbsp;&nbsp;When, you are writing a scalable networking application  
&nbsp;&nbsp;using Event Model of network programming,  
&nbsp;&nbsp;sometimes when processing of certain events take time,  
&nbsp;&nbsp;your event loop is stuck there. With green  
&nbsp;&nbsp;threads, you don't really have a way of paralleling  
&nbsp;&nbsp;your request processing. Packet library, allows  
&nbsp;&nbsp;you to write simple workers, for executing long  
&nbsp;&nbsp;running tasks. You can pass data and callbacks as an  
&nbsp;&nbsp;argument.

&nbsp;&nbsp;When you are going to use workers in  
&nbsp;&nbsp;your application, you need to define  
&nbsp;&nbsp;constant WORKER\_ROOT,  
&nbsp;&nbsp;which is the directory location, where  
&nbsp;&nbsp;your workers are located. All the workers defined in that directory  
&nbsp;&nbsp;will be automatically, picked and forked in a  
&nbsp;&nbsp;new process when your packet app starts. So, a typical  
&nbsp;&nbsp;packet\_app, that wants to use workers, will look like this:

&nbsp;&nbsp;packet\_app\_root  
&nbsp;&nbsp;&nbsp;&nbsp;\>  
&nbsp;&nbsp;&nbsp;&nbsp;\>\_\_ lib  
&nbsp;&nbsp;&nbsp;&nbsp;\>  
&nbsp;&nbsp;&nbsp;&nbsp;\>\_\_\_ worker  
&nbsp;&nbsp;&nbsp;&nbsp;\>  
&nbsp;&nbsp;&nbsp;&nbsp;\>\_\_\_ config  
&nbsp;&nbsp;&nbsp;&nbsp;\>  
&nbsp;&nbsp;&nbsp;&nbsp;\>\_\_\_ log

&nbsp;&nbsp;You would define WORKER\_ROOT = PACKET\_APP\_ROOT/worker

&nbsp;&nbsp;All the workers must inherit class Packet::Worker, and hence a  
&nbsp;&nbsp;general skeleton of worker will look like:

&nbsp;&nbsp;&nbsp;&nbsp;class FooWorker \< Packet::Worker  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;set\_worker\_name :foo\_worker #=\> This is necessary.  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def receive\_data p\_data  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def connection\_completed  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def unbind  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def post\_init  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end  
&nbsp;&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;All the forked workers are connected to master via  
&nbsp;&nbsp;UNIX sockets, and hence messages passed to workers from master  
&nbsp;&nbsp;will be available in receive\_data method. Also,  
&nbsp;&nbsp;when you are passing messages to workers, or worker is passing  
&nbsp;&nbsp;message to master ( in a nutshell, all the internal  
&nbsp;&nbsp;communication between workers and master ) directly takes  
&nbsp;&nbsp;place using ruby objects. All the passed ruby objects are  
&nbsp;&nbsp;dumped and marshalled across unix sockets in a non blocking  
&nbsp;&nbsp;manner. BinParser class parses dumped binary objects and  
&nbsp;&nbsp;makes sure, packets received at other end are complete.  
&nbsp;&nbsp;Usually, you wouldn't need to worry about this little detail.

&nbsp;&nbsp;Packet provides various ways of interacting with  
&nbsp;&nbsp;workers. Usually, when a worker is instantiated, a proxy for  
&nbsp;&nbsp;that worker will also be instantiated at master  
&nbsp;&nbsp;process. Packet automatically provides a worker proxy(See meta\_pimp.rb)  
&nbsp;&nbsp;for you, but if you need to multiplex/demultiplex  
&nbsp;&nbsp;requests based on certain criteria, you may as well define your  
&nbsp;&nbsp;own worker proxies. Code, would like something like this:

&nbsp;&nbsp;&nbsp;&nbsp;class FooWorker \< Packet::Worker  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;set\_worker\_proxy :foo\_handler  
&nbsp;&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;When you define, :foo\_handler as a proxy for  
&nbsp;&nbsp;this worker, packet is gonna search for FooHandler class and  
&nbsp;&nbsp;instantiate it when the worker gets started. All  
&nbsp;&nbsp;the worker proxies must inherit from Packet::Pimp.  
&nbsp;&nbsp;Have a look at, Packet::MetaPimp,  
&nbsp;&nbsp;which acts as a meta pimp for all the workers,  
&nbsp;&nbsp;which don't have a explicit worker proxy defined.

=== A complete Case :

&nbsp;&nbsp;&nbsp;&nbsp;Just for kicks, lets write a sample server,  
&nbsp;&nbsp;&nbsp;&nbsp;which evals whatever clients send to it. But, assuming this 'eval' of  
&nbsp;&nbsp;&nbsp;&nbsp;client data can be potentially time/cpu  
&nbsp;&nbsp;&nbsp;&nbsp;consuming ( not to mention dangerous too ), we are gonna ask our  
eval\_worker, to  
&nbsp;&nbsp;&nbsp;&nbsp;perform eval and return the result to master process, which in  
&nbsp;&nbsp;&nbsp;&nbsp;turn returns the result to happy client.

&nbsp;&nbsp;&nbsp;&nbsp;# APP\_ROOT/bin/eval\_server.rb  
&nbsp;&nbsp;&nbsp;&nbsp;EVAL\_APP\_ROOT = File.expand\_path(File.join(File.dirname(\_\_FILE\_\_) + "/.."))  
&nbsp;&nbsp;&nbsp;&nbsp;["bin","worker","lib"].each { |x| $LOAD\_PATH.unshift(EVAL\_APP\_ROOT  
+ "/#{x}")}  
&nbsp;&nbsp;&nbsp;&nbsp;WORKER\_ROOT = EVAL\_APP\_ROOT + "/worker"

&nbsp;&nbsp;&nbsp;&nbsp;require "packet"  
&nbsp;&nbsp;&nbsp;&nbsp;class EvalServer  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def receive\_data p\_data  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ask\_worker(:eval\_worker,:data =\> p\_data, :type =\> :request)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# will be called, when any worker sends data back to master process  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# it should be noted that, you may have several instances of  
eval\_server in  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# your master, for each connected client, but worker\_receive  
will be always  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# be invoked for the instance, which originally made the request.  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# If you need fine control, over this behaviour, you can  
implement a worker proxy  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# on the lines of meta\_pimp class. This API will change in  
future perhaps, as i  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# expect, better ideas to come.  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def worker\_receive p\_data  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;send\_data "#{p\_data[:data]}\n"  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def show\_result p\_data  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;send\_data("#{p\_data[:response]}\n")  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def connection\_completed  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def post\_init  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def wow  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;puts "Wow"  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end  
&nbsp;&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;&nbsp;Packet::Reactor.run do |t\_reactor|  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;t\_reactor.start\_server("localhost", 11006,EvalServer) do |instance|  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;instance.wow  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end  
&nbsp;&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;# APP\_ROOT/worker/eval\_worker.rb  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;class EvalWorker \< Packet::Worker  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;set\_worker\_name :eval\_worker  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def worker\_init  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;p "Starting no proxy worker"  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def receive\_data data\_obj  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;eval\_data = eval(data\_obj[:data])  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;data\_obj[:data] = eval\_data  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;data\_obj[:type] = :response  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;send\_data(data\_obj)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;end  
&nbsp;&nbsp;&nbsp;end

=== Passing file descriptors to workers :  
&nbsp;&nbsp;Packet, allows this style of load  
&nbsp;&nbsp;distribution as well, you can use method send\_fd to  
&nbsp;&nbsp;pass file descriptors to workers.  
&nbsp;&nbsp;WARNING: This feature hasn't been tested well.

=== Disable auto loading of certain workers:  
&nbsp;&nbsp;Sometimes, you would need to start a  
&nbsp;&nbsp;worker at runtime and don't want this pre-forking mechanism.  
&nbsp;&nbsp;Packet, allows this. You just need to define  
&nbsp;&nbsp;"set\_no\_auto\_load true" in your worker class and worker  
&nbsp;&nbsp;will not be automatically forked. Although name is a bit misleading perhaps.

&nbsp;&nbsp;Now, at runtime, you can call start\_worker(:foo\_worker, options)  
&nbsp;&nbsp;to start a worker as usual. It should  
&nbsp;&nbsp;be noted that, forking a worker, which is already  
&nbsp;&nbsp;forked can be disastrous, since worker names are being  
&nbsp;&nbsp;used as unique keys that represent a worker.

== Performance:  
&nbsp;&nbsp;Although written in pure ruby, packet performs  
&nbsp;&nbsp;reasonably well. Mongrel, running on top of Packet is a tad  
&nbsp;&nbsp;slower than Mongrel running on top of EventMachine. More benchmarks  
coming soon.

== Code:  
&nbsp;&nbsp;&nbsp;SVN Code for packet is on google code, svn repo is:  
&nbsp;&nbsp;&nbsp;[http://packet.googlecode.com/svn/trunk/](http://packet.googlecode.com/svn/trunk/)

&nbsp;&nbsp;&nbsp;Rubyforge URL:  
&nbsp;&nbsp;&nbsp;[http://rubyforge.org/projects/packet/](http://rubyforge.org/projects/packet/)

== Credits  
&nbsp;&nbsp;Francis for awesome EventMachine lib, which has constantly acted as  
an inspiration.  
&nbsp;&nbsp;Ezra, for being a early user and porting mongrel to run on top of packet.

> **···**
>
> --  
> Let them talk of their oriental summer climes of everlasting  
> conservatories; give me the privilege of making my own summer with my  
> own coals.
> 
> [http://gnufied.org](http://gnufied.org)

---

<div class="post-metadata">

**Author:** ![Andre\_Nathan](https://avatars.discourse-cdn.com/v4/letter/a/e56c9b/32.png) [@Andre\_Nathan](https://rubytalk.org/u/Andre_Nathan)\
**Post date:** [20 November 2007 19:55 UTC](https://rubytalk.org/t/ann-packet-a-pure-ruby-library-for-event-driven-network-programming/42381/2 "2007-11-20T19:55:26Z")

</div>

Hemant,

In the eval server example, is a single worker process created,  
corresponding to eval\_worker.rb, or is it possible to create a pool of  
pre-forked worker processes of the same class?

Andre

> **···**
>
> On Wed, 2007-11-21 at 04:14 +0900, hemant wrote:
> 
> > It also provides real easy to user UNIX workers for concurrent programming.

---

<div class="post-metadata">

**Author:** ![Chuck\_Remes](https://avatars.discourse-cdn.com/v4/letter/c/3be4f8/32.png) [@Chuck\_Remes](https://rubytalk.org/u/Chuck_Remes)\
**Post date:** [21 November 2007 00:09 UTC](https://rubytalk.org/t/ann-packet-a-pure-ruby-library-for-event-driven-network-programming/42381/3 "2007-11-21T00:09:54Z")

</div>

Did you ever consider working on the EventMachine project so it could handle your requirements? While I'm happy to see more event-driven programming, I'm puzzled why you re-invented so much of the wheel for one or two features that EM didn't have.

> **···**
>
> On Nov 20, 2007, at 1:14 PM, hemant wrote:
> 
> > Hi Folks,
> > 
> > I am pleased to announce "Packet", A pure ruby library for Event  
> > Driven Network Programming.
> > 
> > Packet is a pure ruby library for writing network applications in Ruby.  
> > It follows Evented Model of network programming and implements almost all the  
> > features provided by EventMachine.

---

<div class="post-metadata">

**Author:** ![Hemant\_Kumar](https://avatars.discourse-cdn.com/v4/letter/h/46a35a/32.png) [@Hemant\_Kumar](https://rubytalk.org/u/Hemant_Kumar)\
**Post date:** [20 November 2007 20:01 UTC](https://rubytalk.org/t/ann-packet-a-pure-ruby-library-for-event-driven-network-programming/42381/4 "2007-11-20T20:01:06Z")

</div>

Andre,

Currently, for each defined worker, only one process is created. You  
can't have a pool of workers instantiated from class.  
I am quite inclined to implement this feature and hence will be coming  
soon. If you can provide a patch, it would be awesome.

> **···**
>
> On Nov 21, 2007 1:25 AM, Andre Nathan \<andre@digirati.com.br\> wrote:
> 
> > In the eval server example, is a single worker process created,  
> > corresponding to eval\_worker.rb, or is it possible to create a pool of  
> > pre-forked worker processes of the same class?
> 
> --  
> Let them talk of their oriental summer climes of everlasting  
> conservatories; give me the privilege of making my own summer with my  
> own coals.
> 
> [http://gnufied.org](http://gnufied.org)

---

<div class="post-metadata">

**Author:** ![Chris\_Carter](https://avatars.discourse-cdn.com/v4/letter/c/a8b319/32.png) [@Chris\_Carter](https://rubytalk.org/u/Chris_Carter)\
**Post date:** [21 November 2007 00:26 UTC](https://rubytalk.org/t/ann-packet-a-pure-ruby-library-for-event-driven-network-programming/42381/5 "2007-11-21T00:26:27Z")

</div>

I think mainly that this is pure ruby, and event machine is a C++ backend.

> **···**
>
> On Nov 20, 2007 6:09 PM, Chuck Remes \<cremes.devlist@mac.com\> wrote:
> 
> > On Nov 20, 2007, at 1:14 PM, hemant wrote:
> > 
> > \> Hi Folks,  
> > \>  
> > \> I am pleased to announce "Packet", A pure ruby library for Event  
> > \> Driven Network Programming.  
> > \>  
> > \> Packet is a pure ruby library for writing network applications in  
> > \> Ruby.  
> > \> It follows Evented Model of network programming and implements  
> > \> almost all the  
> > \> features provided by EventMachine.
> > 
> > Did you ever consider working on the EventMachine project so it could  
> > handle your requirements? While I'm happy to see more event-driven  
> > programming, I'm puzzled why you re-invented so much of the wheel for  
> > one or two features that EM didn't have.
> 
> --  
> Chris Carter  
> concentrationstudios.com  
> brynmawrcs.com

---

<div class="post-metadata">

**Author:** ![Hemant\_Kumar](https://avatars.discourse-cdn.com/v4/letter/h/46a35a/32.png) [@Hemant\_Kumar](https://rubytalk.org/u/Hemant_Kumar)\
**Post date:** [21 November 2007 01:42 UTC](https://rubytalk.org/t/ann-packet-a-pure-ruby-library-for-event-driven-network-programming/42381/6 "2007-11-21T01:42:06Z")

</div>

I would have liked nothing more than having it in EventMachine. But as  
you see the biggest differentiator is  
ability to have process based workers, so I needed low level access of  
sockets. Once started as proof of concept,  
it took off on its own, and I didn't see any harm in having a pure  
ruby version.

> **···**
>
> On Nov 21, 2007 5:56 AM, Chris Carter \<cdcarter@gmail.com\> wrote:
> 
> > On Nov 20, 2007 6:09 PM, Chuck Remes \<cremes.devlist@mac.com\> wrote:  
> > \>  
> > \> On Nov 20, 2007, at 1:14 PM, hemant wrote:  
> > \>  
> > \> \> Hi Folks,  
> > \> \>  
> > \> \> I am pleased to announce "Packet", A pure ruby library for Event  
> > \> \> Driven Network Programming.  
> > \> \>  
> > \> \> Packet is a pure ruby library for writing network applications in  
> > \> \> Ruby.  
> > \> \> It follows Evented Model of network programming and implements  
> > \> \> almost all the  
> > \> \> features provided by EventMachine.  
> > \>  
> > \> Did you ever consider working on the EventMachine project so it could  
> > \> handle your requirements? While I'm happy to see more event-driven  
> > \> programming, I'm puzzled why you re-invented so much of the wheel for  
> > \> one or two features that EM didn't have.  
> > \>  
> > \>  
> > \>
> > 
> > I think mainly that this is pure ruby, and event machine is a C++ backend.
> 
> --  
> Let them talk of their oriental summer climes of everlasting  
> conservatories; give me the privilege of making my own summer with my  
> own coals.
> 
> [http://gnufied.org](http://gnufied.org)

---

<div class="post-metadata">

**Author:** ![Tadeusz\_Bochan](https://avatars.discourse-cdn.com/v4/letter/t/e19b73/32.png) [@Tadeusz\_Bochan](https://rubytalk.org/u/Tadeusz_Bochan)\
**Post date:** [4 December 2007 22:22 UTC](https://rubytalk.org/t/ann-packet-a-pure-ruby-library-for-event-driven-network-programming/42381/7 "2007-12-04T22:22:03Z")

</div>

Hi.  
I was trying out "packet" tonight, but failed at the starting block with

c:/Ruby/lib/ruby/gems/1.8/gems/packet-0.1.0/lib/core.rb:133:in  
`start\_reactor': uninitialized constant  
Packet::Core::CommonMethods::UNIXSocket (NameError)  
&nbsp;&nbsp;from c:/Ruby/lib/ruby/gems/1.8/gems/packet-0.1.0/lib/core.rb:132:in  
`each'  
&nbsp;&nbsp;from c:/Ruby/lib/ruby/gems/1.8/gems/packet-0.1.0/lib/core.rb:132:in  
`start\_reactor'  
&nbsp;&nbsp;from c:/Ruby/lib/ruby/gems/1.8/gems/packet-0.1.0/lib/core.rb:127:in  
`loop'  
&nbsp;&nbsp;from c:/Ruby/lib/ruby/gems/1.8/gems/packet-0.1.0/lib/core.rb:127:in  
`start\_reactor'  
&nbsp;&nbsp;from  
c:/Ruby/lib/ruby/gems/1.8/gems/packet-0.1.0/lib/packet\_master.rb:16:in  
`run'  
&nbsp;&nbsp;from wikipacket.rb:23

I groped around and it seems there is no UNIXSocket support in my Ruby  
installation (ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32])  
on Windows XP.  
Any idea what I'm doing wrong ?

Tad

> **···**
>
> --  
> Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/).

---

<div class="post-metadata">

**Author:** ![Ezra\_Zygmuntowicz](https://avatars.discourse-cdn.com/v4/letter/e/958977/32.png) [@Ezra\_Zygmuntowicz](https://rubytalk.org/u/Ezra_Zygmuntowicz)\
**Post date:** [4 December 2007 23:02 UTC](https://rubytalk.org/t/ann-packet-a-pure-ruby-library-for-event-driven-network-programming/42381/8 "2007-12-04T23:02:39Z")

</div>

Windows does not support UnixSockets. Therefor packet does not run on windows.

Cheers-  
- Ezra Zygmuntowicz  
-- Founder & Software Architect  
-- ezra@engineyard.com  
-- EngineYard.com

> **···**
>
> On Dec 4, 2007, at 2:22 PM, Tadeusz Bochan wrote:
> 
> > Hi.  
> > I was trying out "packet" tonight, but failed at the starting block with
> > 
> > c:/Ruby/lib/ruby/gems/1.8/gems/packet-0.1.0/lib/core.rb:133:in  
> > `start\_reactor': uninitialized constant  
> > Packet::Core::CommonMethods::UNIXSocket (NameError)  
> > from c:/Ruby/lib/ruby/gems/1.8/gems/packet-0.1.0/lib/core.rb:132:in  
> > `each'  
> > from c:/Ruby/lib/ruby/gems/1.8/gems/packet-0.1.0/lib/core.rb:132:in  
> > `start\_reactor'  
> > from c:/Ruby/lib/ruby/gems/1.8/gems/packet-0.1.0/lib/core.rb:127:in  
> > `loop'  
> > from c:/Ruby/lib/ruby/gems/1.8/gems/packet-0.1.0/lib/core.rb:127:in  
> > `start\_reactor'  
> > from  
> > c:/Ruby/lib/ruby/gems/1.8/gems/packet-0.1.0/lib/packet\_master.rb:16:in  
> > `run'  
> > from wikipacket.rb:23
> > 
> > I groped around and it seems there is no UNIXSocket support in my Ruby  
> > installation (ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32])  
> > on Windows XP.  
> > Any idea what I'm doing wrong ?
> > 
> > Tad
> > 
> > --  
> > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C).

---

<div class="post-metadata">

**Author:** ![Clifford\_Heath5](https://avatars.discourse-cdn.com/v4/letter/c/7ab992/32.png) [@Clifford\_Heath5](https://rubytalk.org/u/Clifford_Heath5)\
**Post date:** [5 December 2007 02:45 UTC](https://rubytalk.org/t/ann-packet-a-pure-ruby-library-for-event-driven-network-programming/42381/9 "2007-12-05T02:45:04Z")

</div>

Ezra Zygmuntowicz wrote:

> &nbsp;&nbsp;Windows does not support UnixSockets. Therefor packet does not run on windows.

It wouldn't be hard to use Named Pipes instead, which are the Windows equivalent.

Clifford Heath.

---

<div class="post-metadata">

**Author:** ![Hemant\_Kumar](https://avatars.discourse-cdn.com/v4/letter/h/46a35a/32.png) [@Hemant\_Kumar](https://rubytalk.org/u/Hemant_Kumar)\
**Post date:** [5 December 2007 08:06 UTC](https://rubytalk.org/t/ann-packet-a-pure-ruby-library-for-event-driven-network-programming/42381/10 "2007-12-05T08:06:39Z")

</div>

Never used them, but I will have a look at see, what can be done about  
Windows support.

> **···**
>
> On Dec 5, 2007 8:15 AM, Clifford Heath \<no@spam.please.net\> wrote:
> 
> > Ezra Zygmuntowicz wrote:  
> > \> Windows does not support UnixSockets. Therefor packet does not run on  
> > \> windows.
> > 
> > It wouldn't be hard to use Named Pipes instead, which are the Windows equivalent.
> 
> --  
> Let them talk of their oriental summer climes of everlasting  
> conservatories; give me the privilege of making my own summer with my  
> own coals.
> 
> [http://gnufied.org](http://gnufied.org)

---

<div class="post-metadata">

**Author:** ![Jason\_R](https://avatars.discourse-cdn.com/v4/letter/j/94ad74/32.png) [@Jason\_R](https://rubytalk.org/u/Jason_R)\
**Post date:** [5 December 2007 12:32 UTC](https://rubytalk.org/t/ann-packet-a-pure-ruby-library-for-event-driven-network-programming/42381/11 "2007-12-05T12:32:53Z")

</div>

You do know that there is a maintained pure ruby version of EventMachine  
sitting right next to the C++ extension, right?

Jason

> **···**
>
> On Dec 5, 2007 3:06 AM, hemant \<gethemant@gmail.com\> wrote:
> 
> > On Dec 5, 2007 8:15 AM, Clifford Heath \<no@spam.please.net\> wrote:  
> > \> Ezra Zygmuntowicz wrote:  
> > \> \> Windows does not support UnixSockets. Therefor packet does not  
> > run on  
> > \> \> windows.  
> > \>  
> > \> It wouldn't be hard to use Named Pipes instead, which are the Windows  
> > equivalent.  
> > \>
> > 
> > Never used them, but I will have a look at see, what can be done about  
> > Windows support.
> > 
> > --  
> > Let them talk of their oriental summer climes of everlasting  
> > conservatories; give me the privilege of making my own summer with my  
> > own coals.
> > 
> > [http://gnufied.org](http://gnufied.org)