[ejabberd] Multiple clients over a single connection?

Arne Claassen arne at getorganyzd.com
Mon Oct 20 21:17:09 MSD 2008


I thought about that, but at least by my limited understanding of S2S,  
that would couple processors to a have to run on the same machine.  
I.e. the processor JID sits on the other side of the S2S connection,  
so it must be in the domain of the server that the S2S connection  
impersonates. So moving that jid to another server separately from the  
other processors that share the S2S connection becomes impossible,  
right?

arne

On Oct 20, 2008, at 9:47 AM, Eric Cestari wrote:

> Maybe you could implement your client as an S2S "client" per process.
> That's maybe a lot of work, but that would help on your specific  
> issue.
>
> Eric
> Le 20 oct. 08 à 18:26, Arne Claassen a écrit :
>
>> I was afraid that connections wouldn't be the primary resource  
>> consumer. Well, let me go into my use case and maybe this is  
>> something already supported, i just haven't made the leap from the  
>> protocol specs to how it would be applied.
>>
>> I currently have a system with a bunch of processors, each  
>> identified by a jid. These processors query each other and are  
>> queried by external resources via IQ stanzas. Xmpp basically acts  
>> as a bus so that location of the processors isn't needed to be known.
>>
>> As this system grows, i can see memory on the server becoming a  
>> concern. Since a number of these processors generally live together  
>> in a single processor (right now, most live on one daemon  
>> actually), i really only need a single connection per managing  
>> daemon. But i need the ability to route messages to a named  
>> destination. So, the question is, is there some type of routing  
>> system for clients to register themselves as the destination? I  
>> thought about using pub sub, but that seems a little unwieldy for  
>> doing RPC style communication and i'd be afraid that the pubsub  
>> memory footprint would quickly rival that of the sessions required  
>> to keep each processor at its own jid. Having this routing would  
>> actually enable another use case that i am working towards, i.e.  
>> that processors are spun up on demand by some managing entity as  
>> new messages for an offline processor are detected.
>>
>> Any other protocol features for routing that i'm overlooking?
>>
>> thanks
>> arne
>>
>> On Oct 20, 2008, at 8:36 AM, Mickaël Rémond wrote:
>>
>>> Hello,
>>>
>>> We have some code internally to support that. However note that it  
>>> is not connexion that consume the most memory but session and  
>>> session would still need to be opened (even if you have less TCP  
>>> connexions).
>>>
>>> Le 20 oct. 08 à 01:49, Arne Claassen a écrit :
>>>
>>>> I know this might be out of scope for ejabberd and is more  
>>>> general Xmpp, but is there a way to have a single connection  
>>>> represent multiple JIDs at the same time? I mean the stanzas  
>>>> generally have to and from, so is it possible for a single  
>>>> connection to be the endpoint for a number of JIDs and simply  
>>>> send out its messages and replies encoded with the right from?
>>>>
>>>> I have a number of daemons that talk over xmpp as their message  
>>>> bus. Currently a single physical process can handle a number of  
>>>> these daemons, but i currently require a separate connection back  
>>>> to ejabberd for each one. Since it seems like it takes just under  
>>>> 100KB per connection (maybe that's just per presence and less  
>>>> sockets buy me nothing), it would seem there is a lot of ejabberd  
>>>> memory footprint savings that could be realized.
>>>>
>>>> thanks,
>>>> arne
>>>> _______________________________________________
>>>> ejabberd mailing list
>>>> ejabberd at jabber.ru
>>>> http://lists.jabber.ru/mailman/listinfo/ejabberd
>>>>
>>>
>>> -- 
>>> Mickaël Rémond
>>>  http://www.process-one.net/
>>>
>>>
>>>
>>> _______________________________________________
>>> ejabberd mailing list
>>> ejabberd at jabber.ru
>>> http://lists.jabber.ru/mailman/listinfo/ejabberd
>>
>> _______________________________________________
>> ejabberd mailing list
>> ejabberd at jabber.ru
>> http://lists.jabber.ru/mailman/listinfo/ejabberd
>
> _______________________________________________
> ejabberd mailing list
> ejabberd at jabber.ru
> http://lists.jabber.ru/mailman/listinfo/ejabberd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.jabber.ru/pipermail/ejabberd/attachments/20081020/90282fd6/attachment.htm>


More information about the ejabberd mailing list