If answer is "using xmpp BOSH", then to use BOSH, we need to have in-between CM (Connection Manager) server that would interact with xmpp server. So that xmpp client to CM interaction will then happen over normal http protocol (which will be scalable), but again CM to xmpp server will happen using long-live tcp connection which will cause scalability issue.
How can we make xmpp client-server more scalable??
Bidirectional-streams Over Synchronous HTTP (BOSH) is basically a technology to keep the connection alive to allow the system to send and receive the data to and fro. To be able to use xmpp over the HTTP, you will have to use BOSH.
For you concern about the scalability, you can basically use components which are meant for scalability such as Nginx a component in place of Apache httpd, also there are many connection managers available with Punjab being the most scalable of all. If you are using Openfire as a XMPP server, it has a prebuilt connection manager which has proved scalability.
Related
I'm building a message broker which communicates with clients over ZeroMQ PUSH/PULL sockets and has the ability to exclude clients from messages they're not subscribed to from the server side (unlike ZeroMQ pub/sub which excludes messages on the client side).
Currently, I implement it in the following way:
Server: Binds ZeroMQ PULL socket on a fixed port
Client: Binds a ZeroMQ PULL socket on a random or fixed port
Client: Connects to the server's PULL socket and sends a handshake message containing the new client's address and port.
Server: Recieves handshake from client and connects a PUSH socket to the client's PULL server. Sends handshake response to the client's socket.
Client: Recieves handshake. Connected!
Now the client and server can communicate bidirectionally and the server can send messages to only a certain subset of clients. It works great!
However, this model doesn't work if the clients binding PULL sockets are unable to open a port in their firewall so the server can connect to them. How can I resolve this with minimal re-architecting (as the current model works very well when the firewall can be configured correctly)
I've considered the following:
Router/dealer pattern? I'm fairly ignorant on this and documentation I found was sparse.
Some sort of transport bridging? The linked example provides an example for PUB/SUB.
I was hoping to get some advice from someone who knows more about ZeroMQ than me.
tl;dr: I implemented a message broker that communicates with clients via bidirectional push/pull sockets. Each client binds a PULL socket and the server keeps a map of PUSH sockets so that it can address specific subscribers. How do I deal with a firewall blocking the client ports?
You can use the router/dealer to do this like you say. By default the ROUTER socket tracks every connection it has. The way it does this is by having the caller stick the connection identity information in front of each message it recieves. This makes things like pub/sub fairly trivial as all you need to do is handle a few messages server side that the DEALER socket sends it. In the past I have done something like
1.) Server side is a ROUTER socket. The ROUTER handles 2 messages from DEALER sockets SUB/UNSUB. This alongside the identity info sent as the first part of a frame allows the router to know the messages that a client is interested in.
2.) The server checks the mapping to see which clients should be sent a particular type of data using the map and then forwards the message to the correct client by appending the identity again to the start of the message.
This is nice in that it allows a single port to be exposed on the server. Client side we do not need to expose ports, simply just connect to the server ROUTER socket.
See https://zguide.zeromq.org/docs/chapter3/ for more info.
I'm trying to implement an HTTP proxy for learning and debug purpose.
The support of plain HTTP transactions was pretty straightforward to implement and now I'm looking to implement support for SSL/TLS tunnels.
From RFC 7230:
A "tunnel" acts as a blind relay between two connections without
changing the messages. Once active, a tunnel is not considered a party
to the HTTP communication, though the tunnel might have been initiated
by an HTTP request.
It's not very clear whether I shall build the TLS socket from the socket on which the HTTP CONNECT transaction took place. I assume it is the case, since HTTP is stateless, but I just want to be sure.
When a client connects to an HTTP proxy, CONNECT is used to have the proxy establish a persistent TCP connection with the target TCP server. Then the proxy blindly passes data as-is back and forth between the two TCP connections until either the client or server disconnects, then the proxy disconnects the other party. This allows the client to send data to the server and vice versa, such as TLS packets. This is important so the TLS server can verify the client's identity during the TLS handshake.
So, to answer your question - yes, the client must establish a TLS session with the target server using the same TCP socket that it used to issue the CONNECT request on. Once the CONNECT request has succeeded, the client can treat the existing TCP connection as if it had connected to the server directly. The proxy is transparent at that point, neither party needs to care that it is present.
I want to create a XMPP server on my network and then send message to it with python so that this server can restart the target computer on the network , now how can i set up this server and how can i do the rest of the process?
tnx
I am not sure in what context you are trying to do this, but XMPP has been used in context outside of usual chat and instant messengers (e.g. load balancers, rpc, ...).
There can be several ways of doing this. One way I can think right now is by using Jabber RPC xep-0009 which says:
This specification defines an XMPP protocol extension for
transporting XML-RPC encoded requests and responses between two XMPP entities.
The protocol supports all syntax and semantics of XML-RPC except that
it uses XMPP instead of HTTP as the underlying transport.
Workflow wise here is how you can make this work:
You will need a jabber server which is up and running say on host-A
You will need to configure a startup service on other hosts in the network (say on host-B, host-C, host-D). This startup service is nothing but a xmpp client daemon which will start in the background whenever host is started.
This xmpp client configured as startup service are special in the sense that they will accept incoming rpc calls (support for XEP-0009) and execute received commands on the host.
Received RPC commands can be synonymous to shutdown, kill -9 xxxx depending upon your specific needs.
Finally, xmpp client on host-C can send one or more commands wrapped inside an stanza to xmpp client running on host-B.
You can use one of the existing python xmpp client library and simply extend their working examples for your use case. You will also need to check details on how to configure startup service depending upon your Operating System (e.g. update-rc.d for ubuntu or sc.exe for windows)
When deploying a web application running on a traditional web server, you usually restart the web server after the code updates. Due to the nature of HTTP, this is not a problem for the users. On the next request they will get the latest updates.
But what about a WebSocket server? If I restart or kill the old process all connected users will get disconnected. So my question is, what kind of strategy have you used to deploy a WebSocket server smoothly?
You're right, every connected user will be disconnected if the server restarts.
I think the less bad solution is to tell to the client to reconnect in the onClose method of the client.
WebSockets is just a transport mechanism. Libraries like socket.io exist to build on that transport -- and provide heartbeats, browser fallbacks, graceful reconnects and handle other edge-cases found in real-time applications.
In our WebSocket-enabled application, socket.io is central to ensuring our continuous deployment setup doesn't break users' active socket connections.
If clients are connected directly to sever that does all sockets networking and application logic, then yes - they will be disconnected, due to TCP layer that holds connection.
If you have gateway that clients will be connecting to, and that gateway application is running on another server, but will communicate and forward messages to logical server, then logical server will send them back and gateway will send back to client responses. With such infrastructure, you have to implement stacking of packets on gateway until it will re-establish connection with logical server. Logical server might notify gateway server before restart. That way client will have connection, it will just wont receive any responses.
Or you can implement on client side reconnection.
With HTTP, every time you navigate away, browser actually is creating socket connection to server, transmits all data and closes it (in most cases). And then all website data is local, until you navigate away.
With WebSockets it is continuous connection, and there is no reconnection on requests. Thats why you have to implement simple mechanics when WebSockets getting closing event, you will try to reconnect periodically on client side.
It is more based on your specific needs.
I´ve searched and didnt find which ports does XMPP uses.
I need to implement XMPP server and client and use XML transfer, file transfer and streaming.
Do they use different ports?? Is there a way I can make them use all the same, so I dont need to bother the network admin?
Thanks
According to Wikipedia:
5222 TCP XMPP client connection (RFC 6120) Official
5223 TCP XMPP client connection over SSL Unofficial
5269 TCP XMPP server connection (RFC 6120) Official
5298 TCP UDP XMPP JEP-0174: Link-Local Messaging / Official
XEP-0174: Serverless Messaging
8010 TCP XMPP File transfers Unofficial
The port numbers are defined in RFC 6120 § 14.7.
According to Extensible Messaging and Presence Protocol (Wikipedia), the standard TCP port for the server is 5222.
The client would presumably use the same ports as the messaging protocol, but can also use http (port 80) and https (port 443) for message delivery. These have the advantage of working for users behind firewalls, so your network admin should not need to get involved.
The ports required will be different for your XMPP Server and any XMPP Clients. Most "modern" XMPP Servers follow the defined IANA Ports for Server-to-Server 5269 and for Client-to-Server 5222. Any additional ports depends on what features you enable on the Server, i.e. if you offer BOSH then you may need to open port 80.
File Transfer is highly dependent on both the Clients you use and the Server as to what port it will use, but most of them also negotiate the connect via your existing XMPP Client-to-Server link so the required port opening will be client side (or proxied via port 80.)
The official ports (TCP:5222 and TCP:5269) are listed in RFC 6120. Contrary to the claims of a previous answer, XEP-0174 does not specify a port. Thus TCP:5298 might be customary for Link-Local XMPP, but is not official.
You can use other ports than the reserved ones, though: You can make your DNS SRV record point to any machine and port you like.
File transfers (XEP-0234) are these days handled using Jingle (XEP-0166). The same goes for RTP sessions (XEP-0167). They do not specify ports, though, since Jingle negotiates the creation of the data stream between the XMPP clients, but the actual data is then transferred by other means (e.g. RTP) through that stream (i.e. not usually through the XMPP server, even though in-band transfers are possible). Beware that Jingle is comprised of several XEPs, so make sure to have a look at the whole list of XMPP extensions.