3

I am utterly baffled as to how one gets an Azure role (whether web role or worker role) to communicate with another Azure role?

I've looked at Service Bus Relays and the speed is ridiculous - it took about 6 hours to get data from one role into another role while debugging. When I expose that exact same data via a web service that runs in the cloud I can download that data to my phone in under a minute. Ridiculous. I am assuming the data was being sent from my machine to the cloud, and then from there back to my machine.

Service Bus Relays have a mode called Hybrid where it is supposed to open a direct socket connection to allow for fast communication, but there is literally no documentation on how to accomplish this.

I've exposed a service on one role via the WCF NetTcpBinding, but I don't know how to make the other role be able to call it.

I've also looked at Service Bus Queues/Subscriptions but there is a 256KB limit on the messages you can send!

I cannot believe the lack of documentation and tutorials out there for what should be a common scenario - fast communication between two roles (that are in all likelihood residing on the exact same physical computer!)

Any help is much appreciated, thank you!

Aen
  • 7,433
  • 3
  • 20
  • 21

3 Answers3

3

If your roles belong to the same cloud service they can be reached through the internal endpoints. You can get the internal IP address of your roles and the ports and establish a WCF call.

Here is a topic might help http://msdn.microsoft.com/en-us/library/windowsazure/hh180158.aspx

Shaun Xu
  • 4,476
  • 2
  • 27
  • 41
  • Correct. And with an impressive wealth of documentation and tutorials for what is a common scenario - fast communication between two roles. I should add that queues might provide greater scalability and resiliency. In addition to service bus queues there are the storage service queues. – Fernando Correia Feb 17 '13 at 11:58
  • So... if they aren't in the same cloud service then you have to use public endpoints? – Tim Lovell-Smith Feb 28 '13 at 23:21
  • While this answer may work for multiple roles that are part of the same service (which is bad design in general), my solution has 1 role per service and so this approach does not work. – Aen May 09 '13 at 01:24
0

I did not find any satisfactory answers here, so as a follow up the approach I took was to write the data to sql azure, notify via service bus that there is an update, and let all the subscribers pull the updated data from sql themselves. It works for this particular scenario.

Trying to send the data itself via service bus was prohibitively slow. Using it instead as an inter-role eventing system (using service bus topics/subscriptions) works well.

Aen
  • 7,433
  • 3
  • 20
  • 21
  • You did get an answer from @Shaun that you never even commented about with any type of followup or clarification. Your original question never specified whether your roles where in the same cloud service. – David Makogon May 09 '13 at 00:52
  • 1
    I thought it clear that none of the answers were sufficient. There's only one link posted on this page and basically says to expose your service to the public via a (publicly accessible) WCF service. That was not a sufficient or optimal approach. – Aen May 09 '13 at 01:22
  • Since it sounds like you want to send big packages of data from one VM to another, Azure Storage will likely get you better speed than SQL Azure. See my full answer in the main thread. – Brent Aug 07 '14 at 14:28
0

Did you consider using Azure Storage? It sounds like you want to send big packages of data from one VM to another. A relatively straightforward way to send the data is to use Storage Blobs and Queues. First, write the data to a blob. Then write a message to a queue indicating where data is available (each receiver would have their own queue). The receiver then downloads the message and deletes the Blob. This is slower than a direct socket connection, but also simpler and is asynchronous. Asynchronous communication is a big advantage in a cloud system. With this solution, if the receiver is down for an update it will get the message later when it comes back up.

Brent
  • 101
  • 3