// Copyright (c) 2010 Nokia Corporation and/or its subsidiary(-ies).
// All rights reserved.
// This component and the accompanying materials are made available
// under the terms of "Eclipse Public License v1.0"
// which accompanies this distribution, and is available
// at the URL "http://www.eclipse.org/legal/epl-v10.html".
//
// Initial Contributors:
// Nokia Corporation - initial contribution.
//
// Contributors:
//
// Description:
/////////////////////////////////////////////

#TLS Out of memory test

/////////////////////////////////////////////
[Tlstest]

# READ ME!
#
### This is the range of values for __UHEAP_FAILNEXT that are tested.
### TLS currently requires 846 heap allocations to make a connection.
### If the test has not passed by MaxFailureThreshold then it fails.
### This is to prevent the test running forever if the network or server is down.
#
# The above comment is outdated - in 8.0 it passes on the first iteration with 840.
# The Comms Framework submission increases the threshold dramatically (as can be seen
# below); this is at least substantially due to the new RFileLogger interface since
# every single static logging call now makes an allocation (and the TLS client-side
# has its own logging subsystem, hence a ten row hexdump becomes ten separate RFileLogger
# calls).
# Of course to be a strong OOM test the loop should start at one anyway, otherwise there
# are many states we're not probing. It is suspected that the reason this is not done is two-
# fold: firstly it would take a long time and so mightn't be suitable for routine run and
# secondly and importantly the OpenSSL server currently used on the test network does not
# handle spontaneous socket disconnection and so would need restarting after many of these
# failures. Once a more robust test server is in place this part of the testing needs to be
# revisited.

FailureThreshold=1
MaxThreshold=3200
IPAddress=192.168.40.50
IPPort=543