// 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