Let us take as an example a simple network client application that connects to several computers (servers with a specific version of the VNC server onboard, that is, there is no possibility to change the server part) via TcpClient\SslStream , sends and receives any data, closes the connection. Accordingly, the application is multi-threaded or asynchronous.

Is MSMQ ( System.Messaging namespace) technology intended to replace TcpClient\SslStream and increase performance in this context? And if so, at the expense of what is an increase in productivity?

ps if possible - write a simple implementation example.

  • Something seems to me that Messaging is a high-level shell over TCP, so that it cannot be any faster. But let's wait what the experts say. - VladD
  • I join, MSMQ probably simplifies the implementation of some aspects, but any high-level buns reduce performance in favor of convenience, and sometimes it is imperceptible as in some LiNQ extensions. You can accelerate only by reducing the level of abstraction, and not by increasing. - rdorn
  • Join, just as interesting performance. - Alexis
  • @VladD; There are probably no specialists here, but MSMQ cannot be a high-level wrapper over MS-MPI ( msdn.microsoft.com/en-us/library/bb524831(v=vs.85).aspx )? - Align

2 answers 2

If you look at the list of network protocols in accordance with OSI, you will notice that TCP protocol is at the 4th OSI transport level, while the MQ protocols are at the 7th application level.

This means that no MQ protocol (and they are different: WebSphereMQ, AMQP, etc.) cannot replace TCP. He will work on top of it, taking advantage of his capabilities and complementing them with his own.

A similar situation arises between HTTP and TCP, since HTTP is also at the 7th level.

Answering the second part of the question: performance will be guaranteed to be lower, since the top-level protocols add their own overhead.

What are message queues used for and specifically MSMQ? They provide several possibilities, in particular, the ordering of messages from different places, the reliability of storing undelivered messages, routing, etc. It is convenient to use them for implementing CQRS and Event sourcing patterns ( https://habrahabr.ru/post/146429/ , https://habrahabr.ru/post/149464/ ), and in principle, it is easier to exchange information using a message queue .

Relatively recently, the interbank SWIFT system has migrated, and it may have already been transferred to WebSphere MQ. If you have an idea about this system, then you can immediately imagine which tasks the message queue is good for.

    MSMQ has its own protocol. In terms of "there is no possibility to change the server part" using MSMQ is impossible.

    About the speed of work. The primary goal of MSMQ is not acceleration, but reliability enhancement. Acceleration can be achieved by using a permanent connection instead of constant reconnections, but this quality is not unique to MSMQ. You can easily do the same on sockets.

    Acceleration can also be achieved by using a more reasonable number of threads. Actually if you created earlier on a flow on connection.

    Acceleration can also be achieved through clustering if the application architecture allows, in which case MSMQ takes over the load balancer functions.