I need few pieces of code to talk to each other - they need to be able to send short messages, they need to be sure that messages was received etc..

I looked at Jabber/JXTA, it's way to complicated, I looked at Beep, seems to suffer from the same sickness - specs look ok, but when it comes to implementation you get all that hairy xml everywhere...

So I figure i will have to design the protocol myself, I don't think that's the sanest approach...

In other words - I MUST be missing something, there obviously already were people with similiar requirements, and they just had to design something sane and simple, I just couldn't find it yet... Where should I look now?

For now I figured something like this would be sufficient: 

->EHLO server
<-HELO client
->STARTLS
<-001 OK
->LOGIN USER PASS
<-001 OK
->MSG 001 service12@server.net Hello world
<-001 ACCEPTED 001
<-DLVRD 001
<-MSG service12@server.net Hello to you too

[download]

And we've got few requirements fullfilled:

One another alternative would be two-channel XML-RPC, that would go like this: I want to send message to service12, I connect to xml-rpc server on it's server, and call method message("message"), then it connects back to me and calls confirm() on my xml-rpc server. For interoperation with strange systems replace xml-rpc with soap.
Update: I think it's not a very wise idea to put 'message delivered' confirmation into protocol. There's no need for that, I thought of that because

But on second thought I figured that apps that need that can easily implement on top of any messaging system, and putting it in protocol unnecesarily complicates things.

20040106 Edit by castaway: Changed title from 'Instant Messanging Protocol'

Replies are listed 'Best First'.
Re: Instant Messaging Protocol
by hardburn (Abbot) on Jan 05, 2004 at 14:44 UTC 
    use Net::Jabber qw(Client);
my $jabber = Net::Jabber->new();
$jabber->Connect( hostname => 'jabber_server.domain.com' ); 
$jabber->Connected or die "Can't connect to Jabber server\n";
$jabber->Process(5); # Set a timeout

# Right out of the Net::Jabber::Protocol POD
$jabber->MessageSend(to=>"bob@jabber.org",
                      subject=>"Lunch",
                      body=>"Let's go grab some...\n",
                      thread=>"ABC123",
                      priority=>10);

$jabber->Disconnect;

    [download]

    Jabber might have a lot of extra stuff attached to it, but if all you want to do is send a message, you can ignore most of it. It's certainly easier than creating your own IM protocol, even a simple one.

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

[reply]
[d/l]
[select]

      Little problem here - don't you need a jabber server at jabber_server.domain.com?

      And that's not that simple task, requires significant resources and significant attention from the admin.

      And it doesen't matter if the code can be made simple if it requires more then significant resources, especially in situations when those resources are scarce - for example on embedded platforms. It seems like it's the root of all my problems - people tend to build layers upon layers upon layers of software

[reply]

        Though one of the big servers hosting hundreds of clients might not be simple, you probably don't need that. Net::Jabber::Server contains example code for creating a server, and it's about the same length as the client code above. The only change you'd need to make is to change $Server->Process() to while(1) { $Server->Process() } or similar (probably with some additional error checking).

        If you're doing serious embedded work, why are you using Perl? It's a memory hog. Making your own IM protocol won't change that fact.

        ----
        I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
        -- Schemer

        : () { :|:& };:

        Note: All code is untested, unless otherwise stated

[reply]
[d/l]
[select]
        This might have changed by now, but I remember that when I was working for my previous employer, we had set up our own Jabber server for use within the company. Just install the server software on a server and put the clients out to whomever needs them.

        Update:Fixed grammatical error

        TStanley
        --------
        The only thing necessary for the triumph of evil is for good men to do nothing -- Edmund Burke
[reply]
Re: Instant Messaging Protocol
by valdez (Monsignor) on Jan 05, 2004 at 15:21 UTC

    I would try with Spread Toolkit:

    Spread is a toolkit that provides a high performance messaging service that is resilient to faults across external or internal networks. Spread functions as a unified message bus for distributed applications, and provides highly tuned application-level multicast and group communication support. Spread services range from reliable message passing to fully ordered messages with delivery guarantees, even in case of computer failures and network partitions. Spread is designed to encapsulate the challenging aspects of asynchronous networks and enable the construction of scalable distributed applications, allowing application builders to focus on the differentiating components of their application.
    There is of course a binding for Perl: Spread

    HTH, Valerio

[reply]
[reply]

      Small problems with spread: it seems like it's more of a PVM/MPI replacement then universal messaging platform, and should run in perfectly-trusted environment.

      It seems like there is absolutely no authentication, and any user can pose as any other user/service, this may be fine in tight cluster, but what would you do if you wanted to send message 'Processing finished' to system programmers or support stuff?

      You'd need another messaging platform for that.

      Seems like secure spread fixes some of those consernes though...

      I wonder why it's so hard to get to protocol specs, all people publish these days are 'APIs'.

[reply]
Re: Instant Messaging Protocol
by zentara (Cardinal) on Jan 05, 2004 at 16:44 UTC
    I would use Net::EasyTCP

    It has built in encryption, password logons, and can send hashes easliy in both directions. It isn't suitable for heavy traffic, but can probably handle 10 simultaneous connections nicely, as long as there were no large file transfers, since it uses IO::Select and not forking.

[reply]

      Yeah, it's great, but all it provides is 'inteligent' socket, ie - you get encryption and compression transparently, and it uses it's own tiny protocol for negotiating that, but you still need to figure out some IM protocol on top.

[reply]
Re: Instant Messaging Protocol
by bart (Canon) on Jan 06, 2004 at 13:00 UTC
    Your proposed protocol reminds me very much of SMTP.

    Therefore, as Net::SMTP (and a few others) is built on top of Net::Cmd, I think you might want to take a look at that.

[reply]

      Well, SMTP is quite well designed,

      how do you propose one would do encryption with Net::Cmd?

      It's not an easy task, I already tried it with Net::FTP, and failed.

      Also, Net::CMD follows rather synchronous operation ( you send a command, and then hang until your receive status report for that ), and you can't receive any message unless you check the server. 

      use Net::CMD;
....
$n->command("MSG service12@host.tld");
$x=$n->response();

      [download]
      What happens when I receive a message from someone before server sends 'OK' response to me?

      And that's exactly the main point - most 'classic', well-designed protocol work like that, they don't expect the server to send some message out of the blue (irc being the only exception I know).

      Can you see the problem here?

[reply]
[d/l]

Back to Meditations