Thinking in development
Scilab allows us to call Scilab interpreter from
a C program via some interfaces such as C2F. This
point gives birth to our idea of adding network
function for Scilab with the support of C language.
The requests from clients via the net can be passed
to the Scilab interpreter and the results can be
easily getted and feed back to the clients. Therefore
users can enjoy almost full functions of Scilab
on line with a simple client. The detailed Scilab
documents and irradiative examples(such as “examples/callsci/callsciC”)
make us a strong belief that our idea can come true.
We try our best to make it simple and high-efficient.
The tech-documentation of Scilab Anywhere
1. Glance
The main source code are in the following three
files : sciinter.h , scistream.h ,and SciServer.c.
The rest files just provides some needed C2F interfaces
used by scilab when installing and compiling the
server program.. With these interfaces, it is easy
for developers to use the Scilab interpreters. One
of the most important interfaces is C2F(scirun)(char
* buf, int buf_size), from which all the scilab
commands can be sent to scilab interpreter then
get interpreted and executed in it.
2. Sever program function modules and flow chart
The server program includes following function modules:
1) SciListen: the monitor module
This module is circularly listening at the assigned
port to check if there are requests from the Clients.
Once accept a request, ScilListen module will fork
a subprocess to call the SciProcess module to deal
with the request. After transferring the client’s
net address and connection port to the new forked
subprocess, the SciListen module keeps monitoring
the network for the next connection.
2) SciProcess: the client request processing module
This module competes the TCP connection with the
client, and call other modules to deal with the
requests.
3) SciRecv: the client message receiving module
This module is used for analysis of data packages
from the client. If the beginning three characters
of package are “TXT”, it means that
the message just includes text instructions or scripts.
Then SciRecv will call ExeTxtIns module to deal
with the instructions or scripts. On the other hand,
if the beginning characters are “GIF”,
which means the message includes graphic instructions
or scripts, SciRecv will call ExeGraIns module to
deal with them.
4) ExeTxtIns: the text instructions processing module
This module is used to deal with the text instructions
and scripts. ExeTxtIns directly interact with the
Scilab kernel module.
5) ExeGraIns: the graphic instructions processing
module
This module is used to deal with the graphic instructions
and scripts. ExeGraIns directly interact with the
Scilab Kernel module.
6) Scilab Kernel module
The small but perfect Kernel picked up from Scilab
software.
7) SendTxtIns: the text results sending module
This module is used to send the text results to
the client. The three characters “TXT”
are added to the head of the packages.
8) SendGraIns: the graphic results sending module
This module is used to send the graphic results
to the client. The three characters “GRA”
are added to the head of the packages.
go
to Flow Charts here...
3. Client-Server Communication Protocol
Our Network Programmings are finished with Sockets.
To make it easy to transfer different types of information
between the Servers and Clients, we have worked
out a simple Communication Protocol to ensure that
the servers and clients can receive the right information.
Then followed the detail Client-Server Communication
Protocol: the beginning 16 Bytes is “Protocol
Head”. The 16 bytes are arranged like this:
Bytes 0~3: data type. We have defined two types:
TXT and GIF. Checking these bytes we can identify
if it is a text data stream or a graphic data stream.
The third byte is always set to be 0. Bytes 4~7
represent the byte count, a 32-bit integer, of the
data stream removed the “Protocol Head”
16 bytes. Byte 8~15 are reserved for data type expanding.
By default, these 4 bytes are set to be 0.
