Questions about MSMQ transport

Apr 22, 2011 at 10:01 AM

Hello !

With TCP transport, I can use the same port for different spaces,
how is this for MSMQ [syntactically, this is easy: queue/service]??

There are several ways for messages to be marked, which would allow different
spaces to fetch only "it's" messages ["label" for example].

 

Another question is, how to use mutlicast with AppSpace on MSMQ transport.
MSMQ supports this queuename: "formatname:MULTICAST=234.1.1.1:1234".
There is no way currently to apply such a config string.

If I use the usual way, AppSpace uses MSMQ, which format is used to write them?
I probably need to read the queue by myself, but will keep the AppSpace
infrastructure to send them. Is there any way to have them serialized inside
a self defined structure [to be able to de-serialize them manually]?

Thanks a lot!

br++mabra

Coordinator
Apr 27, 2011 at 9:50 AM

Hi mabra,

- Currently it is not possible to use one message queue for multiple appspace instances. Though it seems that your suggestion using labels wouldn't be too hard to implement. A possibility would be needed to provide a certain label name when starting the appspace, as well as when connecting to another worker.

- We haven't tried multicast queues until now, since the appspace communication is logically always point-to-point (connecting to a certain worker, sending messages to a certain port, ...). If possible, I would prefer using the publish/subscribe mechanisms that are provided by the appspace itself. If you want to try out the transport service with a multicast queue, handing over the queue name should work by using the fluent config:

XcoAppSpace

space = XcoAppSpace.Configure.UsingService<XcoMSMQTransportService>().WithQueueName("formatname:MULTICAST=234.1.1.1:1234")

- A message that is written into a queue by the appspace is serialized in several steps: When an item is posted to a worker or remote port, this item is first enriched with information concerning the worker or remote port (a WorkerMessage or RemotePortMessage object is created), which is needed to identify the correct destination worker/port. This object is serialized (by default using the .Net BinaryFormatter class) and then handed over the transport service. There it is enriched by the source address, as well as some additional information concerning error handling. You can take a look at the TransportHelper class in the MSMQ transport service for details on this. So, if you want to deserialize a message manually, you would first need to apply the deserialization method from the TransportHelper class, and the use a BinaryFormatter to deserialize the content to a WorkerMessage/RemotePortMessage, where the originally posted item is contained. A completely self-defined structure is not possible, but you can replace the BinaryFormatter (=XcoBinarySerializer) with your own implementation, or with the XcoJsonSerializer.
Please tell me when you need any more help on this.

Best regards
Thomas

Apr 27, 2011 at 1:47 PM
Edited Apr 27, 2011 at 2:10 PM

Hi thomass!

Thanks for your explanation! I'll definitively have a look into this.

Just about msmq:Assume you have already a queue or even different ones, if you give it
a multicastaddress later, you can see this as a subscription-registration. msmq will then start
sending all messages for this multicast-address.

I personally have pub/sub never seen [logically] as a point-to-point communication!

br++mabra