TANDBERG 3.0 - Manual (Page 66)

Copyright © TANDBERG 2008 Reference Guide Version 3.0 rev 1.0 62
Appendix D - HTTP Keep-alives
Note: This feature is available from API version 2.4 onwards.
Another method of reducing the amount of TCP traffic when polling the MCU (see Appendix C) via the API is
to use HTTP keep-alives. This method can be used with other Codian products that also support the API, such
as the IP VCR and ISDN GW.
Any client which supports HTTP keep-alives may include the following line in the HTTP header of an API
request:
Connection: Keep-Alive
This indicates to the Codian product that the client supports HTTP keep-alives. The device then may choose to
not close the TCP connection after returning its response to the request. If the connection will be closed, the
device returns the following line in the HTTP header of its response:
Connection: close
The absence of this line indicates that the device will keep the TCP connection open and that the client may use
the same connection for a subsequent request.
The device will not allow a connection to be kept alive if:
• the current connection has already serviced a set number of requests
• the current connection has already been open for a certain amount of time
• there are already more than a certain number of connections in a “kept alive” state
These restrictions are in place to limit the resources associated with kept-alive connections. If a connection is
terminated for either of the first two reasons, the client will probably find that the connection is back in a
keep-alive state following the next request.
The client should never assume a connection will be kept alive.
Also note that, even after a response not containing the “connection: close” header, the connection will still be
closed if no further requests are made within one minute. If requests from the client are likely to be this far
apart then there is little to be gained by using HTTP keep-alives.