Difference between revisions of "Real World Application Integration"

From Nsnam
Jump to: navigation, search
(some notes)
(some notes)
Line 69: Line 69:
 
     }''
 
     }''
 
* Actually there were only one thread running at this time, it use the signal functions of application-defined, many timer functions of the basic protocol-application , and ''select(2)''system all to  monitor I/O operations for multiplexing the events.
 
* Actually there were only one thread running at this time, it use the signal functions of application-defined, many timer functions of the basic protocol-application , and ''select(2)''system all to  monitor I/O operations for multiplexing the events.
*''signal mechanism in quagga''. As we know, quagga application can receive all signals from system and I/O, but it only defined some useful signal and trappec the others avoid large system signal response. Usually,  posix signal can be triggered at anytime from kernel, and it use the kernel execution stack and context, which was asynchronous to the main thread. To avoid these asynchronism, here, in quagga, A ''sigmaster'' was used, which stored the signal information instead of calling handler function immediately when one posix signal was triggered in kernel. Then, the main_thread check out all triggered signals of
+
*''signal mechanism in quagga''. As we know, quagga application can receive all signals from system and I/O, but it only defined some useful signal and trappec the others avoid large system signal response. Usually,  posix signal can be triggered at anytime from kernel, and it use the kernel execution stack and context, which was asynchronous to the main thread. To avoid these asynchronism, here, in quagga, A ''sigmaster'' was used, which stored the signal information instead of calling handler function immediately when one posix signal was triggered in kernel. Then, the main_thread check out all triggered signals of last cycle from the ''segmaster'' and call their handler functions. So, the posix_signals were processed _synchronously_ in the whole application.
last cycle from the ''segmaster'' and call their handler functions. So, the posix_signals were processed _synchronously_ in the whole application.
+
  
 
''2'',  started with Zebra.
 
''2'',  started with Zebra.

Revision as of 13:15, 8 May 2008

Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects

Installation - Troubleshooting - User FAQ - HOWTOs - Samples - Models - Education - Contributed Code - Papers

Project Background

The goal of this proposed project is to develop frameworks and strategies that enable people to integrate already existing code into the simulator. Depending on the application, this can be a straightforward or laborious process, but still should be preferable in many cases to rewriting these protocols from scratch, and hopefully this project can come up with techniques to make these ports even easier.

Here are some initial pointers to how this problem has been worked in the past:

Gsoc Project

Liu Jian(liujatp@gmail.com) started the gsoc project from April 2008.

Abstract

The purpose of the project is to develop frameworks and strategies that enable people to integrate already existing code into the ns-3 simulator, it will be accomplished by integrating Quagga, a routing deamon which implement many useful routing protocols. The project will begin by learning experence that Quagga ever ported to INET simulator, then porting Quagga to ns3 by adding some patchings, through the porting job, summariced,documented and structured properly, a adaption layer or some methodologies for ns-3 will be implemented, through which other real world application will be easily ported by the next person.

Project Plan

  • looking at quagga to identify the system calls it use.functions like socket, time, signal,etc.
  • implememt these function as simu_* in the ns-3-simu tree.
  • porting quagga to ns3.

Status

  • listed all system functions which quagga calls. there is about 30 funs of total 150 need to be implemented in ns-3-simu.

After investigation, there were 4 types of functions.

 1,sockets:
 accept;bind;close;connect;listen;recv;recvfrom;recvmsg;send;sendmsg;sendto;socket;
 getaddrinfo;freeaddrinfo;gai_strerror;getservbyname;getsockname;getsockopt;setsockopt,etc.
                
 2,time:
 ctime;gettimeofday;gmtime;localtime;mktime;strftime;time,etc.
            
 3,signal&thread&process:
 exit;fork;getuid;geteuid;getpid;setpgid;setregid;setreuid;abort;kill;prctl;shutdown;
 sigaction;sigfillset;getgroups;setgroups;sysconf;waitpid,select(2),etc.
                                     
 4,others: 
 daemon;access;openlog;closelog;execv;getrusage;hostperror
 ZCMSG_FIRSTHDR(__cmsg_nxthdr),etc.
  • next: implement these simu_xxx functions(there would be a great job)

started by simple server/client demo code from http://cs.ecs.baylor.edu/~donahoo/practical/CSockets/textcode.html running in ns-3-simu and test simu_x APIs.

  • .......

Detail Schedule

  • ~-4.30 read quagga source code, compile and run simple test; list simu_xxx sys-calls; finish the first step
  • 5.1~5.4 four days vacation
  • ......

About Quagga

basic knowledge

Quagga is a routing soute of 5 routing protocols(RIP,RIPng,OSPFv2,OSPFv3,BGP) based on Zebra, they can be run simutaneously or separately.Zebra layer that contains what is known as the "Routing Information Base" or RIB. Zebra is responsible for maintaining the RIB and for writing routes from the RIB into the kernel forwarding table.

Quagga was planned to use multi-threaded mechanism when it runs with a kernel that supports multi-threads. There may be several protocol-specific routing daemons and zebra the kernel routing manager.The ripd daemon handles the RIP protocol, while ospfd is a daemon which supports OSPF version 2. bgpd supports the BGP-4 protocol. For changing the kernel routing table and for redistribution of routes between different routing protocols, there is a kernel routing table manager zebra daemon. Quagga system architecture, see here http://www.quagga.net/docs/docs-info.php#SEC9.

see more information here:http://www.quagga.net/docs/docs-info.php

some notes

1, Firstly, if we donot care about how one of the protocols runs, we can get some idea about the main code-structure here, which would be useful for porting to ns3.

  • the main thread maintains thead_master, which contains all threads triggered from event, timer, I/O, background,etc; when all initial work was finished, the whole application run as event-driven mode like below:
   main(){
       init_work();
       while(fetch_thread())
           call_thread();
   }
  • Actually there were only one thread running at this time, it use the signal functions of application-defined, many timer functions of the basic protocol-application , and select(2)system all to monitor I/O operations for multiplexing the events.
  • signal mechanism in quagga. As we know, quagga application can receive all signals from system and I/O, but it only defined some useful signal and trappec the others avoid large system signal response. Usually, posix signal can be triggered at anytime from kernel, and it use the kernel execution stack and context, which was asynchronous to the main thread. To avoid these asynchronism, here, in quagga, A sigmaster was used, which stored the signal information instead of calling handler function immediately when one posix signal was triggered in kernel. Then, the main_thread check out all triggered signals of last cycle from the segmaster and call their handler functions. So, the posix_signals were processed _synchronously_ in the whole application.

2, started with Zebra.