serval-devel Mailing List for serval: an internet software VLAN switch

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

www.servalproject.org is not responding.

Saw a June 4 post on your Facebook page asking about it, too.

> Have ou seen the os module?
> os:cmd("...").  :-?
> 

My first news about it .. :D
so many modules and so little time !!
:_(

LsOut = os:cmd("ls"), % on unix platform
DirOut = os:cmd("dir"), % on Win32 platform
jeje

Well. I still think linking would be a better idea. I'm almost done
linking the boot sender to the new facade. I am to start with the link
driver soon. 

To my delight,you should know Mario is taking a look at Serval. :) :_)
He find in it some useful ideas for his auction web in Erlang (which is
his final project). I have just received a mail from him, telling me how
useful was it for him to copy the actual structure of Serval
configuration code. 

He also gave me his messages Trader file. This is an engine that reads
some configuration parameters from a Erlang file and stores in a table.
He uses for internationalize the web. 

I may try, by now, I am just separating the log messages from the code.
I mean:

I have got a messages file like this:

{environment_protocol_value_not_found,"Could not find the default
protocol value in configuration file"}.
{boot_message_error,"Could not load default configuration"}.
{boot_messages_finalized ,"Finalized the load of the default
configuration of the client"}.
{interfaz_already_reserved,"Could not reserve interfaz because its
already in use"}.
{connection_timeout,"Timeout requesting for connection"}.

and then whenever necessary.

?LOG_WRITE(connection_timeout),

When the new client structure would became more reliable, I will send
you some beautiful pictures of the structure. And maybe, some pretty use
cases.. 

I also have in mind to try the cvs, but I must admit I will have to read
a tutorial to manage myself with command orders. Maybe you can recommend
me a "cvs for dummys" on line manual. Man pages don't seem to be enough
to my absent mind. ;)

Cheers!! 

The default configuration of the client is moved to the application
resource file
(client/src/erlang_implementation/ebin/client_application.in)

{application, client_application,
 [
  {description, "SERVAL client"},
  {vsn, "serval_client_0_2"},
  {modules, [client_application, client_supervisor_topsup,
client_genserver_taptoclient]},
  {registered, []},
  {applications, [kernel,stdlib]},
  {env, [{file_log_name,'./erlang_node.log'},
	 {server_address,'localhost'},
	 {server_port,5443},
	 {connection_type,'ssl'},
         {keep_alive_option,'on'},
         {client_time_interval,15000},
         {ssl_cert_file,
"@TOP_FOLDER@/client/c_implementation/certs/client.cert"},
         {ssl_cert_key,
"@TOP_FOLDER@/client/c_implementation/certs/client.key"},
         {ssl_ca_cert_file,
"@TOP_FOLDER@/client/c_implementation/certs/ca-cert.pem"},
	 {tap_ethernet_mac,"FA:23:56:E4:FF:FA"},
	 {tap_driver,'tuntap'},
	 {c_node_name,'c_node@localhost'},
	 {default_server,'localhost'},
	 {default_command_port,'6690'},
	 {default_data_port,'6690'},
	 {default_protocol,'udp'},
	 {default_promiscous_mode,'off'},
	 {default_user_login,'user1'},
	 {default_user_password,'pass1'},
	 {default_vlans_to_join,{['vlan1',
                                  'vlan2']} },
	 {default_vlans_to_create,{[
			{'vlan1','this is an vlan',[]},
		 	{'vlan2','this is an vlan2',[]}
		]}},			
         {shell_node_name,'shell_node@localhost'}
	]}, 
  {mod, {client_application,[]}}
 ]
}.

This will be loaded by the administration_data.
(Im proud of my administration_data VO ) ;) 

-export([start_link/0,
         get_value/1,
	 set_value/2
        ]).

for instance:

miriam@miriam:~/serval/src/client/erlang_implementation/ebin$ ./run.sh
Erlang (BEAM) emulator version 5.4.6 [source] [threads:0]

Eshell V5.4.6  (abort with ^G)
(client@localhost)1> toolbar:start().
<0.57.0>
(client@localhost)2>
client_genserver_administration_data:get_value(default_configuration).
{{ok,localhost},
 {ok,'6690'},
 {ok,'6690'},
 {ok,udp},
 {ok,off},
 {ok,user1},
 {ok,pass1},
 {ok,{[{vlan1,'this is an vlan',[]},{vlan2,'this is an vlan2',[]}]}},
 {ok,{[vlan1,vlan2]}}}

==================================
the interfaz exports.

-export([start_link/0,
	 reserveInterface/1,
	 unreserveInterface/0,
	 connectClientToServer/3,
	 disconnectClientFromServer/0,
	 createVlan/3,
	 deleteVlan/1,
	 joinVlan/1,
	 leaveVlan/1,
	 login/2,
	 setPromiscousMode/1,
	 loadDefaultConfiguration/0,
	 getState/0
        ]).

Interfaz is calling the boot message sender.. 
Now Im linking boot messages to the interfaz 

Cheers!

The New Design of the client:

Its better to implement lots of small processes than few big ones!.
Dividing competences will make the code easier to maintain.

1. two new data processes.(gen_servers)

data_sender 
(receives from taptoclient and sends to server)

data_receiver 
(receives data from server and sends to the clienttotap)

2. The sockets communications will
	-receive command messages from the server and send them to the demux
	-send request from interfaz to the server

3. Demux will ONLY decodE the asn message and send it to the
administrator. (no state)

4. Genfsm_administrator will split into three.

	0. client_genserver_administration_data will only store status of the
client. (get/set operations)

	1. client_genserver_administration receives messages from the demux.
Perform proper actions for each command response. (no state) Update the
administration_data state.

	2. client_genserver_administration_interfaz will be the external
interfaz to the shell and to the boot_message_sender.
	 When a command is requested it will ask the state to the
administration_data and if it is allowed will redirect the request to
the socket communications. (no state)

commands :

interfaz -> socket  ->  server   
server   -> socket  ->  demux  -> administration  

data :

taptoclient -> data_sender -> server
server -> data_receiver -> client_to_tap

Future lines of work:

	- Study the possibility of splitting the socket_communications in two,
and removing the asn packing from the sockets communications.

Cheers!

> > Up to know is for sure we'll be making severe changes into the client.
> > 	- C part will almost dissapear. There will only be erlang node and C
> > part will be linked in erlang. It will have only functions for tapup ,
> > reading and writing. 
> 
> Could you ellaborate a bit more in the motivations of this?

Of course. :) 

https://intranet.igalia.com/twiki/bin/view/Devserval/LinkingIn

>From my point of view, there are three bad issues about the actual way
of communication between the C node and the Erlang Node. The first one
is about Fault tolerance, the second one is about performance, and the
third about competences.

1. Fault tolerance. 
One of the main reasons for have chosen Erlang in the implementation was
that its ability to make a fault-tolerance system. The actual way of
communication between C node and Erlang node suggests us that the C node
is actually monitorizing Erlang node. It should be just the opposite.
The "stable" node should monitorize the "unstable". 

2. Performance 
The C program resides in another OS process than the Erlang runtime
system. This is not acceptable as it is a driver with very hard time
requirements. It is therefore possible to write a program in C according
to certain principles and dynamically link it to the Erlang runtime
system, this is called a linked-in driver. 

Linked-in drivers involves writing certain callback functions in C. Very
good skills are required as the code is linked to the Erlang runtime
system. To call a function in the port drive requires no context
changes, But its also very unsecure, as a fail in the driver makes the
whole erlang node fail.

3. Competences. 
Thus linking in C node into erlang, we should decrease the
responsability of the C node to its almost disappearance. The C code
should only be for reading and writing to tap. We won't need more
trheads, mutex, signals handling, neither no more sincronitation
problems between c node and erlang node, no more duplicated config
files , etc. 

I've not learned yet in detail how to make the link but I've seen some
source code of linked drivers. That seems like making a callback module
in erlang with a certain structure and the C code shall be only few
simple lines for reading writing and open the logical device. 

Cheers!.

Hello,

On Thu, Apr 27, 2006 at 01:06:22AM +0200, Miriam Pena Villanueva wrote:
> I may do the paper you are requesting but i think it is not worth to do
> it because enough information is actually avaliable in the web

For those in the list without access to the Igalia intranet, I should say
that we have plans for moving everything out to the public webpage during
the next weeks. Meanwhile, I am sorry if you receive some information with
references to non-available info or docs. 

> The second point is the description of the performance limitations with
> examples.  That one is exactly what I am already describing in the
> sheduled web of Serval. I am currently analyzing the source code, and I
> have found some mistakes. I'm writing them down in my own notes and some
> of them have already been reported in the web. The reports have a huge
> amount of information explaining in detail what i think is wrong with
> the current implementation and some possible solutions. There are also
> some examples of the problems and their solutions. I'm working on it
> daily. 

That is great.

> The third point you mention is describing a new architecture and I think
> it is too soon to focus on that. First I need to research deeply into
> the bottlenecks of the client and the server. Designing this
> architecture could take me at least one more month, and as it is extreme
> programing, I mustn't do it at once. The proper way would be to focus on
> little problems, modify them and try to know if the solution is more
> efficient. Anyway I want a deeply vision before touching the code.

I was sugesting that because yourself have sent an e-mail proposing a change
in the architecture (separation of data and control in two channels). If you
think you need more time, there is no problem at all :-)

> Up to know is for sure we'll be making severe changes into the client.
> 	- C part will almost dissapear. There will only be erlang node and C
> part will be linked in erlang. It will have only functions for tapup ,
> reading and writing. 

Could you ellaborate a bit more in the motivations of this?

cheers,
juanjo

Hi j.

I may do the paper you are requesting but i think it is not worth to do
it because enough information is actually avaliable in the web

The first point is about the current architecture of serval. As you know
Serval's architecture has not changed since my incorporation to the
project in July. I only focused on performance and fault tolerance
issues. There is a huge amount of detailed information in the
development web, the report Javi made in september and the report I gave
to the University.

The second point is the description of the performance limitations with
examples.  That one is exactly what I am already describing in the
sheduled web of Serval. I am currently analyzing the source code, and I
have found some mistakes. I'm writing them down in my own notes and some
of them have already been reported in the web. The reports have a huge
amount of information explaining in detail what i think is wrong with
the current implementation and some possible solutions. There are also
some examples of the problems and their solutions. I'm working on it
daily. 

The third point you mention is describing a new architecture and I think
it is too soon to focus on that. First I need to research deeply into
the bottlenecks of the client and the server. Designing this
architecture could take me at least one more month, and as it is extreme
programing, I mustn't do it at once. The proper way would be to focus on
little problems, modify them and try to know if the solution is more
efficient. Anyway I want a deeply vision before touching the code.

The fourth point is connected with the second point and is already been
written in the web.

Up to know is for sure we'll be making severe changes into the client.
	- C part will almost dissapear. There will only be erlang node and C
part will be linked in erlang. It will have only functions for tapup ,
reading and writing. 
	- Two ports, data and control.
		- data only udp connections. (some encrypted)
		- control i dont care.
	- 2 erlang processes for each port.reading and writting.
	- Server part will have a process for each vlan with the list of
clients. Syncronization engines. (Observer pattern).
	(... )

As you know, I was sending e-mails with the changes information. As I
couldnt receive any mail from this list I gave up sending them and
continue writting in the web. Anyway, any doubt please report. 

Everybody is invited to check the web. 

Cheers.

Hi Miriam,

On Thu, Apr 06, 2006 at 03:35:27PM +0200, Miriam Pena Villanueva wrote:
> I haven't thought about it yet, but with this separation it could be
> necessarie to develop new processes in the server for each client. If we
> assume we have to implement the "obervers design pattern" i will talk in
> another mail, command channel will encrease with big amount of
> computation that shall not be mixed with data's one.

From the Serval development team it was always more or less clear that the
separation between data and control information would be a good idea. It is
something that was never done because of the lack of time.

I would be nice if you could came up with a 2-3 pages small paper with 
the following structure:
- brief description of the current architecture of serval
- description of the performance limitations with examples
- new architecture proposal with two channels for data and control
- performance advantages of the new approach with examples

If you send that to the list, I am sure we all could try to have a look into
it, discuss for a while, and then you could probably start to implement that
new version.

cheers,
j.

Hello Miriam,

The test seemed to work.

cheers,

j.

Data Channel vs Command Channel. 
================================

In serval_distributed_manager we can see this kind of code. This is
frecuently repeated in connection_operation and many other processes
both in client and server.

handle_cast({send_broadcast_source_to_server,ClientId,MessageData,Timestamp},State) ->
....

handle_cast({send_unicast_source_to_server,_ClientId,DestinationAddress,MessageData,Timestamp},State) 
...

handle_cast({authenticate_plain_request,UserLogin,UserPassword},State) ->
...

handle_cast({join_vlan_request, VlanId}, State) ->
...

handle_cast({create_vlan_request,VlanId,Description,GroupList}, State) ->
..

handle_cast(vlans_list_request, State) ->
...

handle_cast({leave_vlan_request, VlanId}, State) ->

[..many others..]

Erlang's daddy says we can not assume that ordering the pattern-matching
will make the first be evaluated before the other ones. So, even if this
computation time is quite short, if you think of the amount of data
messages that serval is proccesing every second (160 packets sec in
internet???), it could be a big amount of useless effort.

One of the most important tips on improving the performance of Serval
server is to sepparate this channels. Data and control. 

>From my point of view, the best way to implement this separation is
having the data channel in a port and the command channel in another
different. So there will be no code to sepparate this messages in the
server,thus deleting a lot of computation. 

I haven't thought about it yet, but with this separation it could be
necessarie to develop new processes in the server for each client. If we
assume we have to implement the "obervers design pattern" i will talk in
another mail, command channel will encrease with big amount of
computation that shall not be mixed with data's one.

What do you think about this?

As some might know,up to now, there are little bugs in current serval
release I'm trying to get repaired before making the proofs. 

While  my analycing of the SERVAL's source code  some ideas for
improving Serval's performance came up and  I would like to argue then
with you, this time, using the mailing list, in order we all can
help. :)

I am also updating the SchedWeb with these ideas  (Only for igalia's
members , but Javi already working on to make it public).

So thanks for your time and we'll keep in touch 

Cheers!

Thank you
arthur
On Mar 24, 2006, at 3:11 AM, Juan Jos=E9 S=E1nchez Penas wrote:

> Hi,
>
> On Thu, Mar 23, 2006 at 10:17:14AM -0600, a wrote:
>> this is a test
>
> It worked. Welcome to the list!
>
> /juanjo
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting =20
> language
> that extends applications into web and mobile media. Attend the =20
> live webcast
> and join the prime developer group breaking into this new coding =20
> territory!
> http://sel.as-us.falkag.net/sel?=20
> cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D121642
> _______________________________________________
> Serval-devel mailing list
> Ser...@li...
> https://lists.sourceforge.net/lists/listinfo/serval-devel
>

Hi,

On Thu, Mar 23, 2006 at 10:17:14AM -0600, a wrote:
> this is a test

It worked. Welcome to the list!

/juanjo

this is a test

Hi, 

        as you know SERVAL is an R+D project whose aim is to assess the
feasibility of a system to create VLANs using a software server through
Internet. It is a free software project licensed with GPL and its source
code is available in a public CVS repository. 

        The SERVAL development and collaboration team has been working
in the last months to have a first functional prototype. After this
period, I can announce that we have got it and this is the purpose of
this mail, to report this fact to people interested in SERVAL. I would
like to communicate you three more things:

        (A) That we made the decision of changing the top folder of the
SERVAL project in the CVS. We have renamed it from serval-dev to serval.
This information has been updated in the community portal and, besides,
the pertinent configuration changes has also been done.

        (B) That in the last days we have been updating the information
we publish in our community website (http://serval.igalia.com) about the
SERVAL project.

        With the improvements done in the project, as I said before, we
have reached a point in what we think we have a first functional
prototype. Therefore, we have been modifying the community portal to
update the current status of the project, to add the installation
instructions, examples of deployments tested with SERVAL by the
development team and the first developer document.

        The changes in the community web have been:

        => News section. It has been added a piece of news reporting
the participation of SERVAL in the CITSL organized by GPUL in
July.

        => Documentation. It has been divided this area in two subareas:
User documentation and Developer documentation.

                (*) User area. Here several documents were created:

                        -> The installation instructions. The CVS was
reorganized and the compilation proccess has been improved in SERVAL. In
the same way, make a initial SERVAL deployment is more easy.

                        -> Two examples with test deployments made by
the development team were added.

                (*) Developer documentation. It has been designed and
implemented a new SERVAL communication protocol version. An article
explaining this new protocol with its messages was added under this
section.

        => Current status. The article that explains the current
features of SERVAL, its modules, and the opened working lines has been
modified.

           (C) to remark that the installation instructions are and the
SERVAL deployment examples are uploaded in the community web in the
address
http://community.igalia.com/twiki/bin/view/Serval/UserDocumentation and
that the instructions to download the CVS source code are in
http://community.igalia.com/twiki/bin/view/Serval/WebCVS. 

        Finally, I would like to encourage you to download the CVS
repository, compile the source code and test SERVAL; it is not
difficult !!. We would be pleased to have news about the troubles you
find installing it, what features you would like to incorporate to the
project, if you are interested in collaborating somehow with SERVAL or
another issue you want to comment us.

        Greetings !!

-- 
Fco. Javier Moran Rua <jm...@ig...>
IGALIA S.L.

2005	Jan	Feb	Mar	Apr	May	Jun	Jul (1)	Aug	Sep	Oct	Nov	Dec
2006	Jan	Feb	Mar (3)	Apr (8)	May (3)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2015	Jan	Feb	Mar	Apr	May	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec

serval-devel Mailing List for serval: an internet software VLAN switch

serval-devel — Mailing list about SERVAL development