[jdev] Message sending performance XEP-0124

Vaibhav Ranglani ranglani.vaibhav at gmail.com
Tue Jul 5 11:06:12 UTC 2016

I tried the example with directly connection to 5222 and the performance
improved vastly.

I am running into another issue now.

I have setup ejabberd and opened port 5222.

I have setup nginx as a reverse proxy for ejabberd server. The nginx
configuration is as follows.

*stream{    upstream ejabberd-servers{        server ejabberd:5222;    }
server{        listen 5222;        proxy_pass ejabberd-servers;    }}*

*ejabberd* point to the ejabberd server and I am using a docker container
to reverse proxy.

The smack code I am using to connect is as shown below.

*public void createConnectionObject(){    AbstractXMPPConnection conn
= null;    try {        XMPPTCPConnectionConfiguration.Builder
builderConfig = XMPPTCPConnectionConfiguration.builder();
SmackConfiguration.DEBUG = true;
ProxyInfo proxyInfo = getProxyInfo();
builderConfig.setProxyInfo(proxyInfo);        conn = new
conn.setPacketReplyTimeout(100000);        conn.connect();
}catch(SmackException se){        System.out.println("Smack Exception
thrown");    }catch(IOException io){        System.out.println("IO
Exception thrown");    }catch(XMPPException xmppEx){
System.out.println("XMPP Exception thrown");    }    this.connection =
conn;}private ProxyInfo getProxyInfo(){    ProxyInfo proxyInfo =
ProxyInfo.forHttpProxy(xmppHost, 443, null, null);    return

But when I try to make the connection, I get the error
"java.net.SocketException: Unconnected sockets not implemented"

I understand nginx will only serve as a tcp proxy, so any pointers on
how to get this work?



On Sat, Jul 2, 2016 at 3:35 PM, Marcel Waldvogel <
marcel.waldvogel at uni-konstanz.de> wrote:

> With BOSH you can do the same things as with direct c2s XMPP (and even
> more, because guessing an RID is enough). So what should be the security
> concerns of using 5222 directly instead of 5280?
> <https://me.uni.kn/marcel.waldvogel>-Marcel Waldvogel
> <https://me.uni.kn/marcel.waldvogel>
> -----Original Message-----
> From: Vaibhav Ranglani <ranglani.vaibhav at gmail.com>
> To: Jabber/XMPP software development list <jdev at jabber.org>
> Sent: Sa., 02 Juli 2016 11:57
> Subject: Re: [jdev] Message sending performance XEP-0124
> Thanks for the inputs Florian.
> This question is then related to the deployment side. Should I proxy the
> nginx server to ejabberd port 5222? If yes, then can somebody point to a
> post where this has been explained?
> Also wouldn't directly exposing port 5222 to the internet cause security
> concerns?
> Thanks
> Vaibhav
> On Sat, Jul 2, 2016 at 3:18 PM, Florian Schmaus <flo at geekplace.eu> wrote:
>> On 01.07.2016 16:22, Marcel Waldvogel wrote:
>> > For reliability requirements over wireless connections: don't use BOSH;
>> > do use Stream Management (XEP-0198)
>> Exactly. And if you want the BOSH advantage over XMPP's TCP binding,
>> i.e., using standard HTTP(S) ports, then use XMPP's WebSocket binding
>> (RFC 7395) + Stream Management.
>> Some background to this thread:
>> https://community.igniterealtime.org/message/258562#comment-258562
>> I have not much experience with BOSH as I don't/seldom use it. I've
>> merged Smack's BOSH branch when I took over Smack and fixed a few
>> things, but the code should be considered unmaintained.
>> I wonder if BOSH is suitable for mobile environments. In my experience
>> those environments require being able to check the underlying TCP
>> connection for liveness, which is not trivial when using BOSH I imagine.
>> Using the BOSH Technique in mobile environments could cause serious UX
>> issues if the first connection hangs in the long-polling state because
>> the TCP connection broke down silently.
>> WebSocket doesn't have this issues, and provides the same feature set as
>> BOSH when used with Stream Management. I think it is the future and that
>> there is no real reason, besides implementation availability, to use
>> BOSH any more. Sadly there is no support for XMPP over WebSocket in
>> Smack (yet).
>> - Florian
>> _______________________________________________
>> JDev mailing list
>> Info: http://mail.jabber.org/mailman/listinfo/jdev
>> Unsubscribe: JDev-unsubscribe at jabber.org
>> _______________________________________________
> _______________________________________________
> JDev mailing list
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20160705/d6373d4b/attachment.html>

More information about the JDev mailing list