HTTP 1.1 Persistent Connection

[piotr.sarna]

Hello OpenHome team,
I'm working on iOS app that uses your library to create UPnP Control Point for media server. My app will operate in environment with firewall that limits maximum number of active TCP connections to 8 at the time (with 90 secs cooldown). As I observed you create new socket/TCP connection for every UPnP action - so eg. I can invoke 8 browse actions and then I have to wait for 90secs.

Here are my questions:
1. Is there any possibility to encapsulate those actions into one TCP stream via library config?
2. Do you plan to add such functionality?
3. If you don't plan to add this, could you give me some tips where and what should I change?

I will appreciate any help from you side.

Best regards,
Piotr Sarna

[SiMet]

I also like such solution or just information where should I look for fixes

[simonc]

(01-06-2017 11:05 AM)piotr.sarna Wrote:  1. Is there any possibility to encapsulate those actions into one TCP stream via library config?

No, there is currently no way to enable this.

Quote:2. Do you plan to add such functionality?

Nothing that would help with your use case. (We're experimenting with adding extra protocols that can be used with the same proxy classes which use a persistent connection. This wouldn't help with your use case unless you also control the software running on the media server.)

Quote:3. If you don't plan to add this, could you give me some tips where and what should I change?

It'd be quite a substantial change. Action invocation currently goes through the following steps:

• Proxy class reads an Invocation object from the CpiService it (the proxy) owns
• Invocation is populated with details required by this action (service & action names, input arg values, placeholders for output args) then added to a queue of pending actions
• A pool of threads services the queue of pending actions. Whenever an action invocation thread (Invoker object) becomes idle, it reads the next Invocation from the queue of pending actions.
• The Invocation is passed to ProtocolUpnp which creates a TCP connection to the remove device, POSTs the request, blocks until it receives a response then closes the TCP connection. Output arguments are copied from the response into the placeholders in the Invocation.
• Invocation runs a callback in Proxy code. Proxy runs any client-specified callback.
• Invocation is reset and returned to a queue of available actions. Invoker thread becomes available for the next pending action.
  

A lot of different objects would need to co-operate to allow client code to instruct ProtocolUpnp to keep it's TCP connection open and wait for further actions.

One possible implementation could involve a new InvocationStream object. CpProxy could be extended to create/end a stream. Action invocations on a proxy which has an active InvocationStream would note this in each Invocation. Invoker could be extended to check whether it is in the middle of a stream of actions and only accept new actions that are part of that stream (have the same destination device). Action for other devices would need to be returned to the pending queue. ProtocolUpnp could close it's TCP connection when a client signalled it had completed its stream of actions or after a period of inactivity.

I haven't thought this through properly so the above is likely incomplete. Neater solutions will also hopefully exist.