Web服务在TM1300上的实现
加入技术交流群
假定用户在HTTP消息中带有消息体，那么首先要找到一个空白行(即：Cache-Control:no-cache后面一行)，因为它是消息体和HTTP头信息的分界线。接下来需要分析消息主体的内容。这方面的工作非常简单，就是根据字符‘&’将文本串分为三部分，即：xsize=352,ysize=288,submit=%CC%E1%BD%BB。然后根据字符‘=’进一步区分参数的名称和对应的值。通过分析知道参数xsize的值为352，ysize的值为288。
通过对HTTP消息的解析，可以确定用户需要完成的操作及操作所需要的参数，进而可以对底层的硬件或软件进行控制，以完成用户的请求。
由此可以看出，服务器程序的核心工作就是对HTTP数据包解析，决定下一步的处理。针对上面的例子，Web服务程序首先要对视频输入输出接口进行控制，改变输入输出图像的尺寸；接下来还要输出HTTP数据包送给IE浏览器，图3给出了Web服务程序产生的HTTP数据包及用户看到的界面。
图3(a)是服务器回送给IE浏览器的HTTP消息。第一行HTTP/1.1200OK通知IE浏览器，刚才的请求已经被服务器处理。下面一行是服务器的处理时间。Content-type:text/html这一行通知IE浏览器HTTP消息主体部分传送的内容是纯文本格式的HTML网页。后面的空行是HTTP头信息与HTTP消息主体的分界线。当IE浏览器获取HTTP头信息后，就可以根据消息主体的格式调用对应的HTML解析器对内容进行解析，并将解析的结果显示在浏览器的窗口中。
3Web服务进程与其他进程间的通信
由于多媒体处理平台需要同时进行音频、视频处理及网络通信，即在同一个时刻需要有多个任务同时运行，并且这些任务之间需要进行通信，例如：当用户改变了系统编码参数后，Web服务器需要通知视频编码进程，让它们在后续的编码过程中采用新的参数。由于TM1300运行pSOS系统，而pSOS只有进程，没有线程，因此Web服务程序作为一个单独的进程来运行。当需要与其他任务通信时，采用了信号量方法。图4以Web服务进程和视频编码进程之间的通信为例，给出了系统实现进程间通信的过程。
首先在Flash中开辟一块区域，专门用来存储所需修改的参数。当Web服务器接收到客户端提交的修改参数的请求时，采用以下步骤进行处理：（1）Web服务进程将信号量锁定；（2）Web服务进程将用户提交的参数写入到参数区；（3）Web服务器进程释放信号量；（4）Web服务进程向视频处理进程发送信号[3]，通知视频编码进程读取参数；（5）视频处理进程将信号量锁定；（6）视频处理进程读取参数；（7）视频处理信号释放信号量。经过一系列操作后，Web服务器进程和视频编码进程间的通信结束，完成了一次参数的修改。Web服务进程与音频编码进程间的通信与上述过程类似。
本文重点探讨了在TM1300上实现嵌入式Web服务器的方法与具体实现中的一些关键问题。通过在现有的多媒体处理平台中增加Web服务，用户可以采用Web页面的方式来监控硬件的运行状态，并能对系统运行参数进行在线修改，降低了系统的使用难度，提高了交互的友好性，进而增强了系统的功能和可用性。目前，笔者开发的Web服务已经在TM1300上稳定运行，下一步工作主要是扩充其功能，并提供网管功能。
参考文献
1RFC822.StandardforARPAInternetTextMessages[s].1982
2RFC2616.HypertextTransferProtocol----HTTP/1.1[s].1999
3W.RichardStevens著，尤晋元译.UNIX环境高级编程.北京：机械工业出版社，2000
评论