This is a 2009/wk14 version of NoTA H_IN release 3.

Tested with ubuntu relese 8.10

H_IN

====

H_IN upper layer on NoTA stack.

Dependencies

------------

The H_IN core has dependency to following headers:

 - string.h (memcpy, NULL)

 - stdint.h (uint32/uint16/uint8/int32/int16/int8)

The H_IN core does not have any other library dependencies than hplatform.

The H_IN daemon depends on POSIX platform.

Building

--------

autoreconf -i

./configure

make clean all

sudo make install

Daemon (nota_ind)

=================

link against h_in3

Daemons purpose is to provide H_IF to AN and SN process trough posix type of daemon trough posix sockets.

example

-------

you need three terminals A, B and C

Terminal A

h_in/daemon$ ./nota-ind

Terminal B

h_in/test$ .libs/simple_tester_sn

Terminal C

h_in/test$ .libs/simple_tester_an

Single process

==============

link against h_in3_sp

Singleprocess uses h_incore directly, and no other process can use the same h_core.

example

-------

you need two terminals A and B

l_in needs to be configured with actual data bearer like tcp

l_in$ ./configure --with-transports=tcp

Terminal A

h_in/test$ NOTA_LMANAGER=1 .libs/simple_tester_sn_sp

Terminal B

h_in/test$ .libs/simple_tester_an_sp

Multiple reference cores in singleprocess

-----------------------------------------

Starting 2009/wk14 release NoTA H_IN supports creation of multiple instances of H_IN_core component within a singleprocess. This requires that l_in component is configured also to support multiple reference l_in_ups.

Reason for this feature is that developing and testing of multiple stack within same process.

example with singleprocess l_down

---------------------------------

full stack picture

AN | ref H_IN_sp | ref L_UP | ld_single | ref L_UP | ref H_IN_sp | SN

requires following L_IN configuration.

l_in$ ./configure --with-transports=single --enable-multi-reference-l_in_up

l_in$ make clean all && sudo make install

requires following h_in configuration.

h_in$ ./configure --enable-multi-reference-h_in_core

and now simple tester an sn single process can be run with

h_in$ test/.libs/simple_tester_an_sn_sp

Simple Tester

=============

Simple tester is test harness to test the h_in features. It is combined from two applications,

one designed to run on service side, one designed to run on client side.

simple tester is located in h_in/test/simple_tester*

there exists multiple version of simple tester for different purposed.

	_sp

	the ones ending with _sp are linked against h_in3_sp and no daemon is run while using 

	single process version. Ones not having _sp on their application name are needing nota_ind

	to be runnable.

	_an

	The ones having _an in their application name, are having client side features built in.

	Client side features are the options which test cases are to be run. Default action is to

	run all test cases.

	 -e 3 4      enables only test cases 3 and 4

	 -d 3 4      disable test cases 3 and 4 and runs everything else

	_sn

	The ones having _sn in their application name, are having service side features built,

	mainly means that these can responce to client side requests.

Look for the examples in above mentioned configurations options.	

Branch coverage

===============

Branch coverage is used to determine which parts of the code gets run. H_IN in default uses

'gcov' coverage package included in gcc compiler collection. "--enable-coverage" parameter 

in ./configure scripts enables value "-g -O0 -ftest-coverage -fprofile-arcs -static" is set to

CFLAGS variable. This generates branching functionalities in compiled code as well as it enables

linking to gcov library, to enable runtime support of coverage features. To be able to do

branch coverage in libraries static linking needs to be enabled. 

enabling and building

---------------------

Coverage is enabled with --enable-coverage flag to configure script. It is recommended 

that possible old files are cleaned with command 'make clean_coverage'. Command 'make clean all' 

cleans binary files and forces coverage support files to be generated.

   h_in$ ./configure --enable-coverage

   h_in$ make clean_coverage clean all

After the branch coverage configurations have been done, desired softwares can be run from where the 

h_in branch coverage is aimed to study.

gcov results

------------

There is a script file to help getting results of coverage run. It requires a directory where to

store the results as a parameter. The rest of the parameters will be passed to the actual

gcov call as parameters.

   h_in$ ./coverage.sh gcov_result

or for more detail

   h_in$ ./coverage.sh gcov_result -b

lcov results (in HTML format)

-----------------------------

lcov_coverage.sh script file helps getting results of coverage run in HTML format. It requires a 

directory where to store the results as a parameter.

   h_in$ ./lcov_coverage.sh lcov_result