tcp.im ideas

a scratchpad, a little bit of a brain dump.

***Notification, The scalability issue

At some point we’re probably going to be limited in the number of instant messages that we can send out.

Im’s are a 1:1 medium, im chat rooms are a many:many medium. In theory, a workgroup could subscribe to a chatroom, and as long as a bot held it open, could participate in a messaging medium where you could sent to all of the members of the room as easily as sending one im to an individual. There’s a little bit of hairy code required to make keep everyone in the room invited, which may turn out harder then just running down the list of people who want notification.

I haven’t seen this call in the api, but I suspect that lurking out there somewhere is a Send Message to all buddies method. That would make subscription lists essentially buddy lists, and once again making notification a single sent message.

***The 2k limit.

Aim has a 2k message limit, but we don’t have to be limited to AIM or other size limited channels. We have http. Aim’s strengths are that it’s a lightweight bus for quick messages between entities that are at unknown locations across the net. The only thing that we do know about them is that they have an open tcp/ip connection to AOL’s servers. this implies that the other end most likely has web access of somr form or another.

We can use an out of band data chunk to makeup for the small size limit, at least when sending from radio or a full peer frontier system with the http server running. We can either: upstream the body/attachment to /upstreamBase/imblobs/string.md5(some unique key) or map a url to the body in the frontier case. The other side would see the “big im rpc” message with the associated url, grab the content, and process from there. The hash is so that we can put content in a directory without having others poking around and having a likelyhood of finding anything. If there’s any response, or after some timeout, the sender can drop the link or delete the upstreamable file.

It’s unclear if we’d want to encode this in a im message or a gotourl message (at least from the aim case)


An aimuser/pw/connection thread is similar to a service in user.inetd. User.inetd opens a listener for connections, IM opens a tcp connection then listens for packets from the AIM server.

The various messages that can be sent across (chat room, im, gotourl, etc.) are similar to the get/post/any methods of the http responder. By this analogy, mainresponder.respond is called by the any method of the default responder, the particular on_im_in method would be called by the im responder that picks up the request.

Does it make sense to design the im responder system so that it assumes that it will be trivial to run more than one resonder on different usernames? Prehaps pointing at a different responder table?

If we want the driver structure to take more than one connection in stride, we’re going to want to pass the address of the connection info so that the send method will be sending from the correct screenname. (eg, send(adrData, username, message)). That change is goign to have to percolate through the entire responder hierarchy.

Alternatively, we could set up a page table for the response, and store the pointer there. Any item that really needed to get to the connection info could get it through the pagetable. Or. If the im system needs it, it could set up the page table before calling into the tcp.im.server method. (this is sort of predicated on the threaded response model.)

***The other methods.

Almost all of the work and talking we’ve done up to this point has been on the on_im_in, do_send_im basis. Simple is good, and there is a lot that can be done with these. The other interesting api areas are in the chatrooms. We can certainly program a bot that will enter a chat if invited, or set up a chatroom and invite others.


3 Comments so far

  1. Commenter May 12th, 2002 10:56 am

    Hi Eric

    Forgive me if I’m talking out of turn or have missed something, but I’d like to comment on the 1:1 vs many:many thoughts above, wrt scalability. Have you considered pubsub in this context? That would provide 1:many.

    Plus: (mass) dissipation of messages no longer the sender’s responsibility
    Minus: Small setup cost (recipients must subscribe to the publisher), although this is not unique to pubsub (e.g. recipients must enter room in groupchat)


  2. Commenter May 13th, 2002 9:02 am

    I’m not sure that I get what you’re saying about pubsub. (perhaps this is part of jabber that I haven’t seen?)

    The group chat idea is nice, but I think it might fall down in the face of having to maintain presence in a chat room, especially if one must be invited in.


  3. Commenter May 14th, 2002 12:19 pm

    Hi Eric

    I was responding particularly to the first part of what you wrote (notification and scalability) – in that you (seemed to) express concern about sending out many notifications in a 1:1 messaging context. All I was saying is that a pubsub mechanism built into Jabber [1] might be the solution you’re looking for – one ‘publisher’ wants to notify many ‘subscribers’. The publisher has to only send one message, and the pubsub mechanism diffuses that message to all the subscribers. Hence the scalability problem (if I understood your concerns correctly) goes away from the actual RU end of the picture.

    sorry if I wasn’t clear before

    [1] pubsub in Jabber is achieved by agreeing on a standard for using certain packets – there’s a pubsub proposal here, for example : http://www.jabber.org/jeps/jep-0024.html

Leave a reply

You must be logged in to post a comment.