|
在这里把自己看application模块的一些笔记整理一下贴出来，和大家一起交流。
说到application模块，首先得先说说application configure和profile configure。
在online document中有着详细的介绍（Main Menu中的Models->Model descriptions->Methodologies & Case Studier->Configuring Application and Profiels）。
这里简单说一说：profile用来描述用户的行为的：用户使用什么类型的应用，什么时候使用这样应用，使用多久？
application具体描述应用的动作，比如说http应用，就规定每次取得页面的大小和时间间隔。一个profile可以包含多个application。
不知道大家看过application 模块的代码没有，其实它里面做的东西就是要解析你在application configure和profile configure中的设置。
在workstation的application module中gna_clsvr_mgr PM的start状态Exit Execs中的最后一句gna_client_params_parse ()负责解析profile和application。
在gna_client_params_parse ()里对“Profile Descriptions”中的每一项通过调用gna_client_profile_parser ()进行解析。
这里以destination为例说一说OPNET是如何解析的。
在gna_client_profile_parser ()中会进行symbolic与real destinations的映射。
/* Get mappings between symbolic and real destinations */
if (type_value != GnaT_ApType_Custom)
gna_client_actual_servers_parse (dest_preferences_objid, server_name_ptr, nam_appl_ptr);
在gna_client_actual_servers_parse（）把“Actual Name”的设置解析出来。
这里的“Selection Weight”很重要，因为是从目的地址中根据权重随机选择的：
在具体某个应用如：FTP，在gna_ftp_mgr PM 中需要连接具体哪个server的时候，会从列表中选择的：
/* Select a server among the list of servers corresponding to the */
/* symbolic server name.*/
ftp_client_info_ptr->server_name = app_server_name_select (application_info_ptr);
app_server_name_select（）是在tpal_app_support.ex.c中实现的：
/* Get a random number between 0 and 1. */
reqd_weight = op_dist_uniform (1.0);
/* Loop through the list of servers. */
for (server_index = 0; server_index < application_info_ptr->server_count; server_index++)
{
/* Get weight of server and increment total weight. */
total_weight += application_info_ptr->appl_servers_ptr [server_index]->selection_weight;
/* Stops when total weight is higher than required weight. */
if (total_weight >= reqd_weight)
{
/* Get the name of the server */
server_name = application_info_ptr->appl_servers_ptr [server_index]->server_name;
break;
}
}
这样就实现了对目的地的解析。当然啦，你也可以不必指定目的地，这样OPNET会自动选择网络中supported相应service的wkstn或server作为destination。
此解析出进行业务仿真所需要的参数。上面只是提到了destination的解析，对于其它参数的解析大同小异，起码有一点是很相似的，那就是让你看代码看到烦！
然后调用gna_nam_profiles_start()为每一个profile定制起始时间，就会从wait状态进入到spawn_profile状态。在spawn_profile中首先根据你在profile configure中的设置为这一个profile定制结束中断和下一次启动中断。然后调用gna_profile_mgr子进程，同时提供一块共享内存，传递这一profile解析出来的信息。
在gna_profile_mgr中也是同样的分析，根据profile中设置了的application调用相应的子进程，后面的事情就简单多了，不必详细说了。
前面所说的都是client端的操作，如果是server的话，就根据client发来的请求提供相应的服务。即进入了arrival状态。感兴趣的可以看看，代码好像也不多了。
这里所涉及到的东西一般的应用，如果是vedio或voice的话，又有所不同。在start状态中，根据在server中是否supported voice或video，假设supported voice，那么就会调用gna_passive_voice_client_spawn()来首先注册voice服务，然后create子进程gna_voice_called_mgr，invoke它（打开被动连接），如果有client端建立主动连接，那么就会从wait转到open状态，同样的再调用gna_passive_voice_client_spawn（）为该请求创建一个子进程与之建立连接，此后如果从client端有数据传送过来，那么就会直接invoke相应的子进程进行通信。
基本上application模块所做的东西就是这些，其中还包含有一些ACE相关的东西，这里就不提了。
再说一点，如果是要改动application中的代码的话，也有两种方案。
一是套用OPNET提供的application configure和profile configure的机制，自己添加application模块新的Model Attibutes，还有配套的解析程序。如果是这样子做的话，需要更仔细的看懂application的流程，不能像我上面那样泛泛而谈就算了。要不漏了什么地方没改对就别怪我了。
二，很简单，自己重写一个application的PM呗，不管OPNET的那一套东西，只要和下层的接口能连起来就行了。
呵呵，再补充一些。
如果是自己重写application的话，有些地方是需要注意的。你看那些什么gna_vedio_called_mgr的进程，最后发数据的时候好像很简单，就是用op_pk_send就行了。事实上也就是那么简单，但是得有一个前提，就是要先把连接建立好了。
首先要在server端要调用tpal_service_register ()来注册一个service，具体入口参数大家可以查查文档。然后调用 tpal_session_open_passive()来打开一个被动连接。而在client端是不需要注册service的，只需要调用tpal_session_open_active()来打开一个主动连接。双方建立好连接后，就可以简单的通过op_pk_send()来传输数据了。要不，packet到了tpal层就不会处理了
到那个tpal层，可能大家都不是很熟，因为这个东西应该是OPNET自己加上去的吧。是应用层和传输层之间的一个适配层吧。正如上面所说的，application要用到tpal的一些函数来建立连接。具体数据到了tpal层后会怎么处理就没有研究过了。大家可以在online document中看看tpal层的介绍。 Mani Menu->Model Descriptions->Transport Adapation Layer
|
