Manoj,

membox uses shared memory to get messages in. It is theoretically possible
to write interraces to it on any language that supports shared memory
queues.

I'm planning to develop a reference implementation on this, probably using
an abstraction library that Stipe proposed. Stay tuned.

Regards,

Alejandro

On Wed, Apr 16, 2008 at 1:52 AM, Manoj Raul <[EMAIL PROTECTED]> wrote:

> Hello Alejandro
>
> can u please tell me how can membox will be used with external language
> like java?
> if yes how ?
> what will be exact flow of technology ?
> waiting for your reply
>
> Regards
> Manoj
>
>
>
>
> On 4/14/08, Alejandro Guerrieri <[EMAIL PROTECTED]> wrote:
> >
> > Dear Devs,
> >
> > I've commited the first deployment of membox to CVS.
> >
> > The goal for this box is to provide a simple yet fast method for MT
> > injection, and also to provide a bridge to kannel from other languages.
> >
> > The box waits on a shared memory queue for messages to come in. When
> > received, it sends the messages to bearerbox. Since messages are being
> > passed using shared memory, it's _very_ fast.
> >
> > A model client application is on the "test/" folder. It enqueues 10.000
> > messages in just a couple of seconds (to smsc "test"). I'm planning to add
> > some more control to this (control the smsc, from, to and message fields).
> > At the end, it would be very similar to fakesmsc, but on the client side.
> >
> > From a single client test, sometimes the queue get stuck on message #43,
> > and the only fix is to stop the box, remove the ipc queue (ipcrm -q #id) and
> > start again. I'm still clueless about what could be causing this, maybe
> > someone with more IPC experience than me could see where the problem is.
> >
> > I'm still have to do some concurrency tests (I mean, run two or more
> > test_send instances at the same time and see if messages are lost/mixed) but
> > I want first to solve the "message #43 bug".
> >
> > Anyway, please feel free to jump into the project, make changes and
> > suggestions.
> >
> > Best regards,
> >
> > Alejandro Guerrieri
> >
>
>

Reply via email to