[JDEV] My evil plans for a client.

arh14 at cornell.edu arh14 at cornell.edu
Fri Aug 6 12:38:35 CDT 1999

On Fri, 6 Aug 1999, Thomas D. Charron wrote:

>   Jer would be a better person to talk to about that..  Basically, there is
> nothing that makes client to client IMPOSSIBLE, and anyone could implement
> it..  Problem is, you lose all tracking ability, along with now being
> chained to that client, and nopt being able to say, go into another room
> and start up a client and continue the conversation..  Merely the way 
> we implemented it.. 

Hmm...clients could register for event callbacks like: "Buddy#1 has an 
additional IP address, broadcast to both now"

>   And the servers themselves can do reletivly well without needing to do
> alot..  All they do is decide where to send stuff..  That's it..  A 
> 486/66 could handle 250 some users fairly easily, IMHO..

Hopefully more than 250 people will come on board (ok, you can run a 
multitude of boxes though).  It'd need a humongous amount of bandwidth to 
transfer everybody's message (250 ppl * @1 msg/minute * @500 bytes a 
message...we'll ok, you win...that is a very paltry sum ;)

Not critiquing, just adding ideas,

> On Fri, 6 Aug 1999 12:12:37    arh14 wrote:
> >
> >I might not be all that familiar with the Jabber architecture, but is it 
> >entirely client-server?  There are no peer-peer connections?  How about 
> >deferring a lot of the work to peer-peer connections?  I can see the 
> >Jabber "server" as basically a bulletin board for who is online/offline, 
> >etc.  Messages can go directly between client endpoints right?  Was there 
> >some previous discussion about this and a resolution to be purely 
> >client-server?  If so, then that server better be prepared to handle a 
> >whole honking bunch of load.
> >
> >My idea was that clients would authenticate to the server and get a 
> >session ticket.  Via mutual trust of the server, clients would be able to 
> >authenticate to each other, and pass messages encrypted with tickets.  
> >This is a classic 3-tier Kerberos model.  In fact, the whole system could 
> >be based on Kerberos, as Kerberos is application independent.
> >
> >This would make it very very hard to spoof messages, and at the same time 
> >unload work to the client (let send a 10 gig file to 
> > cares).
> >
> >Anyway, security mechanism aside, my question is just whether peer-peer 
> >connections were ever considered and reasoned against.
> >
> >Aaron
> >
> >
> >On Fri, 6 Aug 1999, Thomas D. Charron wrote:
> >
> >>   Please, do..  Expandibility and choice is a feature, not a bug.. ;-P
> >> 
> >>   My only concern is file attachments..
> >> 
> >>   In order to do this correctly, we need to have the negotiation system intact and working..  My main concern here is offline file storage..  The servers need to be able to refuse packets based on size.  There's a whole ball of wax here that I really haven't though about, and I'm not sure about Jer..  Here's a few things the transports AND etherx routers need to be able to do:
> >> 
> >> 1) Somehow state the maximum packet size allowed..  This is a convience for clients, see below for what happens if they don't listen..
> >> 
> >> 2) If a packet reaches a predefined size, disconnect, delete all data that that message EVER existed, and send a nastygram to the from addy, along with an info message to the dest user.
> >> 
> >> 3) Keep track of and monitor maximum server side storage..  Aka, if an offline file get's X big, refuse all future messages for that user, with an error stating that they have exceeded their server side storage limitation.
> >> 
> >>   Without these, script kidies start sending their /boot/vmlinuz files several hundred times to a user..  'KaBloom!'.  The jabber spool directory get's to gigs, and possibly downs the server..
> >> 
> >>   For that matter, perhaps a client feature would be 'maximum possible packet size'.  If it reaches a certain peak, it prompts the user if they want to abort..  (Aka, send nasty message to server, ban user, and disconnect/reconnect)..
> >> 
> >>   
> >> ---
> >> Thomas Charron
> >> 
> >> On Fri, 6 Aug 1999 08:30:23    Scott Robinson wrote:
> >> >Because I love the sound of a crossplatform, clean Jabber client... I've
> >> >started prototyping one. =D I hope to have all the fun features and love
> >> >that everyone feels a need for. Plus, I'll end up killing all you suckas
> >> >once I get running. ;) wxWindows is good.
> >> >
> >> >But back into reality, I'd love to make another suggestion for client fun.
> >> >MIME support! Messages encoded in MIME (and the clients have a rudimentery
> >> >(sp?) mailcap) could allow for a whole new world of kick-ass messenging. Why
> >> >send text when I can send an encoded mp3? (ed. Let's hope we're all on cable
> >> >modems or better.) I want to send my breakup message with a little "I will
> >> >survive" MIDI attached. You can see where I'm going with this...
> >> >
> >> >As for my 3l1t3 soon be started client... keep looking for it.
> >> >
> >> >Scott.
> >> >
> >> 
> >> 
> >> --== Sent via Deja.com http://www.deja.com/ ==--
> >> Share what you know. Learn what you don't.
> >> 
> >> _______________________________________________
> >> jdev mailing list
> >> jdev at jabber.org
> >> http://mailman.jabber.org/listinfo/jdev
> >> 
> >
> >_______________________________________________
> >jdev mailing list
> >jdev at jabber.org
> >http://mailman.jabber.org/listinfo/jdev
> >
> --== Sent via Deja.com http://www.deja.com/ ==--
> Share what you know. Learn what you don't.
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev

More information about the JDev mailing list