Frequently Asked Questions

The Linxter SDK is currently supported on Windows XP, Vista, Windows 7, Windows Server 2003, Windows Server 2008, and Azure. The machine must have the .NET 3.5 Framework installed.

Future versions of it will support Google Android, iPhone, Windows Phone 7 and Linux.

Linxter has security built in at many layers, so that messages are secure from point-to-point. Messages in the API local data store are encrypted, the service calls from the API to the ISB use username token authentication and authorization, and the ISB back-end services run under secure middle tier identities and do not impersonate the caller identity.

All messages are encrypted using X.509 certificates. This provides for end-to-end security, regardless of the number of intermediaries involved in transferring the message and regardless of whether or not the transport is secure.

Messaging between program instances can only occur if a communication channel (digital contract) exists between them. You can specify what programs are permitted to establish communication channels with instances of your program.

When a program instance sends a message, it is queued in a local data store, until it has been successfully transferred to the ISB. Messages in an outbound queue on the ISB are stored until they are successfully received by the retrieving program instance.

If your program is trying to send or receive messages but is experiencing a temporary loss of Internet connectivity, then the API automatically enters into a retry mode and connects to the ISB once the issue is resolved.

With assured information delivery, a core feature of Linxter, even if your program instance loses its network connection during the sending or receiving of a message, or if another failure interrupts the process, the transaction resumes with the message intact whenever the issue is resolved.

Another reliability and efficiency feature built into Linxter is chunking. For example, let’s say you are sending a message with a 100MB file attachment, and after transmitting 70MBs, the sending or receiving program loses its Internet connection. When the connection is re-established, the process picks up from where it left off. Reliability features like this are especially important with wireless (and its frequent interruptions in connectivity) becoming the norm.

Yes. You do not need to open special holes in your firewall or those of your remote offices, business partners, or customers. Linxter uses TCP and HTTP as its transport protocol for sending and receiving messages.

You are not constrained to any specific formatting. The contents of your message can be sent as XML, MIME, plain text, a proprietary encoding, or even encrypted cipher text.

Yes. A message can have zero to many associated attachments that get sent along with the message. File attachments can be identified as paths to files or passed as binary resources.

Yes. When registering a program to the ISB, a developer can choose how many instances of their program are allowed to be activated. This setting can be used to control the pace of deployment, or used as a security measure if there are a specific number of known users. This setting, like all settings in Linxter, can be updated at anytime.

Communication channels are created only after a communication channel request is sent and approved. For more details, click here.

There are three ways channel requests can be created:

• Manually
• Automatically
• Programmatically

When registering a program to the Linxter ISB, you specify how you want communication channel requests handled by instances of your program. There are three options to choose from:

• Automatically Accept
• Require Approval by Web Manager Account
• Require Approval by Program Instance

Yes. When registering a program to the ISB, you have two options. You can allow instances of your program to receive channel requests either from any program, or only from programs you whitelist.

When registering a program to the ISB, a developer can choose how long a message is allowed to live in an outbound queue on the ISB if it is not picked up. The data contained in some messages might only be relevant for short periods of time. This feature allows you to keep outdated communications from being received. This is especially important for machine-to-machine transactions, or time-sensitive data in which only the most recent data is needed.