[JDEV] My evil plans for a client.

[arh14 at cornell.edu]

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 192.143.2.10 send a 10 gig file to 
192.143.2.11...who 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
>