[standards-jig] Fw: Potential problem in the future

Thomas Muldowney temas at box5.net
Tue Jan 21 04:42:01 UTC 2003


Wow I don't read stuff well, stupid wandering mind, anyway, I think you
could accomodate multiple s2s components in a manner similar to c2s as
well.  If you wanted to put it in 1.4.x

--temas


On Tue, Jan 21, 2003 at 03:13:02PM +1100, Robert Norris wrote:
> > I am sure this has become apparent to some of you already but it just
> > dawned on me so I thought I would share it.  Jabberd currently on a
> > linux box, suffers from a 1024 session limit per port.  This could
> > cause some serious problems in the future when jabber really takes hold
> > on the market.  Not so much in client limitations but in s2s
> > limitations.
> 
> The easiest way around this that I'm aware of is to have multiple s2s
> "components" (in quotes because its not always implemented as a seperate
> component). This could be done in a limited fashion right now using 1.4
> - one s2s (the catch-all service) will be used for outgoing connections,
> but you can setup as many as you wanted, all listening on different IP
> addresses (or ports) and running in their own processes, listening for
> incoming connections.
> 
> These ports can be balanced in all the normal ways (layer 4 switching,
> DNS round-robin, or even some clever stuff using SRV weights).
> 
> To be able to use more than one s2s for outgoing connections requires
> some support from the router, but this could be worked around by writing
> a proxy connects to a router as a single s2s service (and the catch-all
> service), and then accepts connections from multiple s2s components,
> each in their own process. Nick Perez is working on something very
> similar to this at the moment (if I understood him correctly ;) ).
> 
> For services that can't afford large numbers of s2s components (because
> they don't have the hardware, or the spare IPs, or special switching
> equipment, or control over their DNS, or any combination of these ;) )
> it would be possible to write a s2s component that drops connections
> after they've been idle for a certain amount of time, or perhaps once it
> has, say, 1000 open connections (so it staus under the 1024 limit). s2s
> connections don't have to remain open, its just more efficient to keep
> them open. It's entirely possible to open a connection, do dialback,
> send a single packet and then close the connection. Everything will work
> fine, it'll just be a bit slower.
> 
> And you can always increase the number of available file descriptors per
> process, if your operating system supports it.
> 
> Now I've got some fun ideas :)
> 
> Rob.
> 
> -- 
> Robert Norris                                       GPG: 1024D/FC18E6C2
> Email+Jabber: rob at cataclysm.cx                Web: http://cataclysm.cx/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20030120/768d56ea/attachment.sig>


More information about the Standards mailing list