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.
Related
I am working on an automation project using Raspberry pi and Windows IoT. Is it possible to broadcast to a web page, similar to Server-Send-Event? I am monitoring certain events and instead of calling server every few seconds for updates, I would like server to send the alert to web page direct. Any help would be greatly appreciated.
I think you can use WebSockets. WebSockets are an advanced technology that makes it possible to open an interactive communication session between the user's browser and a server. You can refer to this sample. Or you can use IoTWeb to embed a simple HTTP and WebSocket server into your application.
Update:
WebSockets are a great addition to the HTTP protocol suite, but there are numerous situations where they cannot be used.
Some companies have firewalls that will prevent WebSockets from
working.
If you are deploying software in a shared hosting
environment, you may not be permitted to use WebSockets.
If you are
behind a reverse proxy that isn’t configured or the software doesn’t
support pass-through of WebSocket protocol, WebSockets won’t work.
Another option is long polling,the browser does an XHR request and the server simply doesn’t respond until it has something to send. But in this way, if you want to do 2-way communications with the server, you are effectively using 2 sockets. One is tied up hanging/waiting for the long poll response, and the other is sent by the client to send new information to the server. Long polling is also problematic because the client has to be able to handle XHR errors, some of which are tricky to handle or even impossible to handle. You can search more differences and disadvantages from internet.
I want to learn how the XMPP protocol works by analysing the network packet flow, but all the XMPP contents are encrypted. Is there a way to make them not encrypted?
I'm using Openfire as the XMPP Server and Spark as the Client. I've tried to set Server Property "SSL Enabled" to Disabled, but it didn't work. I've also tried the SSLKEYLOGFILE + Wireshark way, but that only works for browser not XMPP Server.
XMPP clients will prefer to use encryption, if available. This hampers packet inspection (for all the good reasons). To be able to inspect XMPP traffic, you'll have to disable client connection encryption server-sided. This will prevent clients from using encrypted connections when communicating with the server. Note that clients can still choose to encrypt the content of their communications, through the use of OMEMO or OTR-like end-to-end encryption strategies.
To disable client connection encryption in Openfire, open the admin console, and navigate to Server > Server Settings > Client Connections.
There, open the 'advanced settings' option of the first block, and select 'disabled' for the "STARTTLS policy" option.
If your goal is to learn about XMPP, there are alternative, and potentially easier ways. XMPP is an open standard and is well documented. A very good way to learn about XMPP is to read it's specification at https://xmpp.org/extensions/ (Start with RFC6120 and RFC6121).
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've been asked about the possibilities for writing an ejabber module for an internal application. I am opposed to the idea, but I'm not sufficiently familiar with xmpp to support my response, and perhaps I'm wrong.
When google did wave they chose xmpp; and I understand that choice; real time communication between multiple people. Same goal here.
...but it feels to me like a customized server plugin isn't the right answer.
The issues I see are:
1) You lose sync with the server development and have to go through merge hell to ensure security updates, patches, etc. on the server are patched.
2) Any heavy customization of the server means you're probably expecting to be passing special mark up messages to interact with the server plugin; that means you'll have to do heavy client customization as well.
There is an alternative route:
Standard XMPP server. two customized xmpp clients; one for the client and one for the server.
The server client opens a connection to the XMPP server and sits and waits.
Multiple front end clients open connections to the XMPP server and then use xmpp to open connections optionally: 1) to each other and 2) to the server client user.
The front end can then perform real time updates by talking to the server client. It can even subscribe to multiple server client users and have incoming 'activity streams' for multiple different concurrent tasks.
This has the advantages of:
1) You only need to solve the XMPP problem once (client library)
2) Your application server is never externally visible; only the XMPP server is externally visible, which is massive security win.
3) You can use whatever XMPP server infrastructure you want without any issue.
4) You will never have a server update that causes your application server to become 'legacy' and unable to use those apis any more (short of a complete XMPP protocol update).
Downside:
You application server client needs to be complicated enough to handle multiple requests, or have multiple workers or something (but this scales using resource fields and have multiple application servers from different machines connecting to the XMPP network).
...but, I'm not that familiar with the technology.
Is there any reason why the alternative I've suggested would be worse than a customized xmpp server?
XMPP is used in Google Wave/Wave in a Box only for Federation, i.e. only for server to server communications. This is in order to take advantage of existing XMPP capabilities like discovery protocol. The messages are transported in binary form between servers inside XMPP packets. The Web clients use WebSockets/Socket.IO to communicate with the server. Actually that was the reason to argue about developing an alternative pure HTTP based Federation protocol.
Does using web sockets actually mean browsers will be able communicate with xmpp servers (any other IM servers) directly ?
Thx.
No. Allowing TCP-level access to arbitrary servers would cause all kinds of security problems. Imagine a website which caused every user to connect to an SMTP server and start sending spam emails… suddenly you have a massively distributed spam attack, especially if combined with an XSS attack on a major site. Web Sockets has a small amount of framing around it designed to make such attacks impossible, without adding too much overhead over TCP.
One day. It's likely that we'll define an XMPP sub-protocol for websockets that can replace BOSH(XEP-0124/0206) when both the client and server support it. In the meantime, BOSH is widely implemented.
you can think of HTTP polling ....
and transfer xmpp data along 8080 port..