Do I *really* need RPC and NETBIOS to use transactional NServiceBus queues between local servers and Amazon EC2?

Question

We have been trying - without success - to get transactional message queues working between local servers and our cloud servers up in Amazon EC2.

We're using NServiceBus, and have got the pub/sub examples and various other trivial apps working locally between here and EC2, but trying to spin up the components of our actual application is proving... vexatious.

As far as I can work out, to allow a local server (DYLAN-PC) to send a message transactionally via a queue on an Amazon EC2 instance, I will need to:

1. Enable NETBIOS name resolution (e.g. via the /etc/lmhosts file) at both ends
2. Allow RPC connections to be initiated from either end (so open port 135 for RPC plus various other ports)
3. Configure MSTDC on both systems, enabling remote connections and inbound/outbound connections

Have I missed something? In particular, the requirement to allow NetBIOS in an age where everything (including Active Directory!) runs on DNS seems particularly archaic. Are we doing something stupid trying to use MSMQ between sites like this? This is the first big project where we've tried this kind of distributed architecture, and the deployment/configuration is starting to hurt so much I'm convinced we've taken a wrong turn somewhere... a little perspective or advice would be gratefully received!

Answer 1

If you're look to build a geographically distributed system, where you can't arrange a VPN between these sites, you should be using the gateway capabilities of NServiceBus to communicate over alternate transports (like HTTP) between those sites.

Answer 2

RPC is required for reading from remote queues. If you push to remote queues and pull from local queues, you won't be using RPC.