According to xep-0065 bytestream can be bidirectional. I have tested openfire and ejabberd and it looks like its contains only unidirectional bytestream service.
So the question is: is there some xmpp server with bidirectional bytestream (or it is possible to setup it on openfire/ejabberd) or maybe some external proxy65 server?
You can try the poxy server at https://github.com/mmatuska/proxy65 this often works
Related
I am using the gorilla websockets package to make a server to handle web-socket connections from clients. I am using the sockets to send a json array of ints. I was wondering if there is a way to verify if all the data got transferred to the client without corruption. Any help would be great, Thanks
I'm trying to implement file transfer via xmpp, my server is openfire 3.9.3.
I have tried to imitate Sparks' stanzas and I got to a dead end.
please help!
file transfer is already implemented in xmpp servers like openfire.
You need to implement it in client side.
Check strophe js or candy js, there is an API to do this.
Helo, I'm working on a mobile game which needs realtime communication from client to server.
Usually I'll implement a TCP socket server and use some private binary protocol to enable bidirectional communication, and now I also looking into XMPP server like Ejabberd which is based on standard. But XML in some way it's really redundant and inefficient, especially for mobile app it could means more traffic and memory consumption.
Is it a MUST that XMPP use XML?
Is there any XMPP implementation that uses binary as low level data format instead of using XML? (or I shouldn't choose XMPP and start with other standard or technology.)
Any strategy to reduce overhead of sending complex data object (not big file object) using XMPP?
XML is required by the XMPP specification, so there are no binary implementations. It does indeed contain much more overhead, but you have to keep in mind the problem XMPP is designed to solve - an active chat connection can be expected to transmit maybe one message per second.
As for the Google talk api: they use a non-xml protocol for client - Google server connections. When I send a message in the Gmail client, the request body just contains a bunch of post data:
count=1&ofs=16&req0_type=m&req0_to=my.friend%40gmail.com&req0_id=6A8466CBC59CBB0C_0&req0_text=test&req0_chatstate=active&req0_iconset=classic&req0__sc=c
That part is not XMPP. The server which accepts this request then does the job of creating and sending out the XMPP requests. The XMPP is still in XML, they just use a different protocol between the client and Google server.
I searched source code of openfire , but did not find any file working for XEP-0234. Can anyone else give me an answer, as I am new to openfire and not sure about it.
There is no special server code required for XEP-0234. The server must route only iq stanzas for it from client to client. This is defined in the XMPP core protocols and supported by every XMPP compliant server.
I am tasked with creating a text messaging system with low bandwidth server to server connections. The other developers already use protobuf to send data for other parts of the system between these same server locations, and it would be helpful to continue that trend for the text messaging portion. Server to client connections are not bandwidth constrained. It would be great to be able to use an unmodified chat client and openfire xmpp server.
What is better to program in this situation, a component for openfire or a transport for Kraken?
Have you tried enabling XEP-138 compression on the server-to-server link? Even if OpenFire doesn't support XEP-138, it will be easy to add, and should provide better results that almost any naive translation to protobufs.