HTTP 1.1 Persistent Connection
|
01-06-2017, 11:05 AM
Post: #1
|
|||
|
|||
HTTP 1.1 Persistent Connection
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 |
|||
26-06-2017, 09:10 AM
Post: #2
|
|||
|
|||
RE: HTTP 1.1 Persistent Connection
I also like such solution or just information where should I look for fixes
|
|||
28-06-2017, 10:46 AM
Post: #3
|
|||
|
|||
RE: HTTP 1.1 Persistent Connection
(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:
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. |
|||
« Next Oldest | Next Newest »
|