AMPS Client objects are capable of concurrent publishes and subscribes to multiple topics on an AMPS instance. These objects are designed to handle multiple subscriptions and publication to multiple topics. However, each Client object can only connect to one AMPS instance at a time.
In most cases, you only need one AMPS Client object per AMPS instance you're connected to. If you subscribe to multiple topics using asynchronous message processing, the Client will dispatch to the correct callback, as you provided at subscription time. If you subscribe to multiple topics using MessageStreams, the client will route messages from each subscription to the correct MessageStream.
There are a few limitations enforced by the AMPS server. As noted above, an AMPS Client can only connect to a single AMPS instance at a time -- that is, each object represents a single connection. Each connection has a specific message type and authenticates to AMPS with one set of credentials. If your application needs to connect to multiple instances of AMPS, needs to use different credentials for some reason, or needs to use different message types, you will need a Client object for each connection.
Likewise, while a Client object can both publish and subscribe, and is safe to use from multiple threads, when you use asynchronous message processing you cannot send commands to AMPS from the background thread managed by the Client (concurrent access from other threads is fine). See the Developer Guide for more details: this is a case where you will either need to dispatch the commands to another thread (such as worker threads in a thread pool), or create a separate Client to send commands back to AMPS.
The information above applies to HAClient objects, as well.
Keywords: multiple subscriptions, multiple topics, publish and subscribe from same object, client multithreading, concurrency, deadlock