Data types (i.e. classes) have abstract and concrete aspects. We store the abstract aspects in header files (using c++ this is the .h file) and the concrete aspects in implementation files (cpp file). In the header we define the data type’s signature, export interface (public part of a class), parameters, methods, properties. Using C this kind of approach is shown better because header files can be separate from the implementation well, while in C++ sometimes you must store implementation specific properties in the header (usually in the private space).

The more information we define in the header file in connection with the implementation, the harder to change the implementation later without changing the header file. It can be a problem in a complex and huge software, where changing something in a deeper layer can result more hours compilation time.

In my example I show you an implementation of the stack data type. Stack is a very simple type, we can push elements to it, pop these elements out and get the number of the stored elements. The stack can be implemented in different ways, we can use vector or linked list to make it work.

In this example I’m going to store integer value in it.

There’s a problem with this header file. Using int *entries assumes we want to use array to store values. However it’s good for shorter stacks, since handling larger stack is not so efficient, because we have to allocate in the memory the whole size of the stack at the beginning. Later, when you want to change it to linked list to it can be more efficient in memory consumption, you must recompile every part of your software that includes this header file.

Using another structure we can change very easy to different implementation without to compile the software again. Considering the next change:

stack_impl structure gives opportunity to define properties in the cpp file. Stack_size is a property of the stack, so it can be in the header file.

In the cpp file that’s using linked list, the stack_impl looks like this:

and with array:

The implementation with linked list (stack.cpp) is:

And the implemantation with array (stack2.cpp)

Using this somewhere (let this be the main.cpp), we can call the stack’s methods:

Create the object files using g++:

  g++ -c main.cpp
  g++ -c stack.cpp
  g++ -c stack2.cpp

Finally we create two different executable code:

  g++ stack.o main.o -o linked_list
  g++ stack2.o main.o -o array

So for unit testing I would create only a cpp file and put the class declaration and definition there inline, because it doesn’t have any implementation code that we want to hide. I guess the unit test be simple, perspicuous and brief, so guys, don’t separate it…

Gondoltam megpróbálom szemléltetni a számítógépes hálózatok működését, mert úgy vettem észre egyetemen sokan csak dobálóznak a szavakkal, de hogy mi micsoda, az néha megválaszolatlanul marad.[OFF] Mikor elkezdtem ezt a blogot, nem gondoltam volna, hogy lesz valaki aki olvassa. Meglepetés erejével hatott az a 30 látogató is, még ha nem is olvasták végig, erőt adtak hogy folytassam. Nehéz gondolatokról írni, de megpróbálkozom vele… [/OFF]

Egyetemünkön mindig nagy para van hálózatok évfolyamzh előtt. Újra előkerülnek a kedves kis algoritmusok, Dijkstra, Bellmann-Ford, megint ellepik az 53-as portot a dig lekeresek, es sorolhatnam. A problémát ott látom, hogy senki sem tudja mit miért csinál, copy paste, ide ezt kell írni, oda meg azt. Talán mondhatjuk, hogy a tömegképzés hátránya? A következő pár sorban csak egy kis képet szeretnék mutatni az anyagról, nem oktató jelleg, csak hogy legyen egy kis képünk a dologról.

Próbálok szemléltetést adni az egész tárgyhoz, kicsit az ELTE-s oktatás oldaláról. Sajnos nálunk 1 félévig oktatják, ebben is teli lényegtelen dolgokkal, de mit tehet az ember. Ez van. Megjegyezném, ez nem doksi, ez csak csupán pár gondolat összefűzése.

Az, hogy hogy alakult ki a hálózat, nem mennék bele. De minthogy az informatika az élet digitalizálása, 0-1-re alakítása, így a minta, amire épül nem újkeletű.

Képzeljük el a következőt. Levelet szeretnénk küldeni egyik nagyon jó ismerősünknek. Fogunk egy papirt, ceruzát, megírjuk levelünket, borítékba helyezzük, elszaladunk a postára, majd a posta eljuttatja barátunknak. Ha válaszol rá, akkor pár nap múlva ott lesz a ládánkban a levele. A számítógépes hálózat olyan mint egy postai rendszer. Posta meg már mióta létezik. Na szedjük össze, mi mi is egész pontosan.

Először is, meg kell írnunk a levelet. Vegyünk egy txt filet. Miután megírtuk, fogunk egy borítékot. Ez a boríték felelős azért, hogy más ne tudja elolvasni, és hogy ellássuk olyan információkkal, hogy kinek is küldjük. Ezért lesznek felelősök a csomagolások (amikor fejlécezzük őket).
Na igen. Hogy kinek is küldjük. Az életben mindenkinek van egy postai címe, név, utca, házszám, város, irányítószám. A címe mindenkinek egyedi (az irányítószámot most még ne keverjük bele), elég érdekes lenne, ha egy másik ember kapná meg levelünket, úgyhogy az adatok teljes mértékben rá illenek. Ezért felelős a MAC Address. A MAC Address nem más, mint a hálózati eszköz beleégetett kódja (na jó, ha ügyes az ember megváltoztathaja). Ez alapján mindenki egyedi. A Mac address-el viszont van egy kis probléma. Honnan tudjuk, merre is van az a szerencsétlen célpont. Ez körülbelül olyan, mintha nevet írnék, meg utcát. Talán egyszer megérkezne levelünk, de nem garantálnám biztosra. Kell egy mód, ami alapján levelünk a leggyorsabban ér célba.

Mikor a borítékra felírjuk az irányítószámot, kihangsúlyoznám, irányító!!, azt mondjuk meg a postának, hogy merre fele küldje. Minden posta rendelkezik egy számmal, és a posták közötti forgalom ezekkel a számokkal történik.
Most a példa megkönnyítéséért mindenkinek legyen egy postafiókja, ezzel egyszerűbb lesz követni.

Vegyünk hálózatokat. Hálózatok ugye gépek összekapcsolása. Tehát definiálunk egy közös tulajdonságot, melyre ha illeszkedik egy gép, akkor egy hálózatban vannak. A mi esetünkben egy hálózatban legyenek azok a postafiókok, melyek egy irányítószám alá esnek. Remélem idáig egyértelmű. Az IP cimünk nem más, mint az irányítószám és a postafiókunk egyfajta kotyvaléka. De mi is az az IP cím?

Az IP-nek (Internet Protokol) jelenleg két verziója él. A 4-es és a 6-os. Amiről most szó lesz, az a 4-es verzió, a 6-os még csak az előszobában jár, a mobil-távközlés fogja a nappalinkba terelni. Az IP cím 4 darab 8-bites számból áll, ezeket ponttal választjuk el. 8 bit => 0..255. A 0-nak és a 255-nek kitüntetett szerepe van, ilyen címet nem kaphat gép. Ez alapján tudunk elérni egy gépet. Elrugaszkodva a postától, ez olyan mint egy telefonszám. Amikor azt mondom, hogy 192.168.1.1, akkor ez egy 4-es verziójú IP cím. Egy hálózati eszköz több ilyen címmel is rendelkezhet (több postafókunk is lehet), de egy IP egy géphez tartozik (1 postafiók csak egy 1 személyé lehet). Valahogy definiálnunk kéne azt a közös tulajdonságot, mely alapján 2 gép egy hálózatba kerül. Erre való a netmask. Ez a netmask olyan mint egy maszk. Innen is ered a neve. Most képzeletben vegyünk két ugyanolyan hosszú bináris számsorozatot. Legyen mondjuk a 100110 és a 101001. Az első legyen a cím, a második a mask. Most helyezzük rá a maskot a címre, ahol egyes van, ott legyen az eredeti szám, ahol nulla, oda ne írjunk semmit. Mi a következőt kaptuk: 1_0__0. Ahol _ jel van, oda írhatunk 0-t vagy 1-et, ahol szám, az változatlan. Amely cimek ezek után erre illeszkedik, az a hálózat tagja lesz. Tehát 110110, 100100 egy hálózatba kerülnek, mert a séma mindkettőre illeszkedik. Most még egy gyors példa. Szeretnénk egy olyan hálózatot, mely 2 gépet számol. 192.168.1.1, legyen az egyik cim, 192.168.1.3 legyen a másik cím. Ekkor a gépek az utolsó előtti bitben térnek el, tehát a netmask 255.255.255.253 (mert a 2^1-n változik, és az 255-2=253), az IP amire pedig illesztek, az a 192.168.1.1. Amúgy ha azt írnám, hogy 192.168.1.0/24, az azt jelenti, hogy az IP cím első 24 bitjének változatlannak kell maradnia, de az utolsó 8 bitre, a mi esetünkben a 0 helyére, bármit írhatunk, azok a gépek egy hálózatban lesznek. Létezik továbbá olyan, hogy broadcast, ez egy kitüntetett IP cím, ez felelős azért, hogy egy csomagot minden gép megkapjon. Például azt szeretnénk elküldeni minden gépnek, hogy kapcsoljon ki. Ilyenkor a broadcast cimre küldünk egy kikapcs üzenetet és ilyenkor ezt az összes, a hálózatban lévő gép meg fogja kapni.

Tehát ez alapján már tudunk gépeket csoportosítani. Most nézzük hogy jut el egy boríték egyik helyről a másikra.

A postára érkezik egy levél, amin van egy irányítószám. Mi is történik ezután. Fogja a hölgy a levelet, megnézi hogy a szám ugyanaz-e, mint az ő ir.számuk. Ha igen, akkor berakja a kiküldésre váró levelek közé. Ha nem, megy a központba, majd ott eldöntik mi legyen vele. A központba megérkeznek a levelek, van rengeteg zsák, az egyik zsák az 1-essel keződőek, a másik a 2-essel, és így tovább. Majd amikor megtelik egy zsák, megnézik a számot, és ha 6-ossal kezdődik akkor megy az Alföldre, és így tovább. Majd az Alföldi központban nézik a második  számot, megint zsákba, és így tovább (csak Kecskemét száma ugrott most be…).
Gondolom találkoztunk már azzal a szóval hogy Router. Ha otthon több gépünk van, akkor biztos fent van egy a falon, de léteznek ezekből az eszközökből hatalmas példányok is. A router nem más, mint az a hölgy, vagy úr, aki a leveleket zsákokba rakja. A router olyan, mint egy polip. A lábain hálózatok vannak, és van egy kitüntetett lába, ez lesz a GateWay. Jön egy levél, ami egy IP címmel rendelkezik, mégpedig a címzettel. A router megnézi a címet, majd megnézi létezik e olyan hálózat valamelyik lábán, amire ez a cím illeszkedik. Ha nem, akkor a kitüntetett lábra kerül, vagyis a GateWay-re, majd talán ott eldöntik mi legyen vele. Vagyis amikor a postán a kisasszony megnézte, hogy az irányítószám ugyanaz-e, mint az ő számuk, akkor ha igen, akkor ment az egyik lábon a fiókba, ha nem, akkor gateway-re rakta, majd a feljebblévők eldöntik mi is legyen vele. Megjegyezném, hogy minden gépnek van routing táblája, és minden gép ezáltal egy router. Ha ezt most olvasod, akkor egyben egy router előtt is ülsz, aminek a gateway ága ott lóg hátul…

Ha jobban megnézzük, a levelek egy gráfon (pontok, melyek vonalakkal vannak összekötve) vándorolnak, ahol a csúcsok a posták, élek pedig a postások útja, vagy a vonaté ami szállítja, stbstb. Mondjuk Debrecenbe nem úgy szeretnénk eljuttatni levelünket, hogy elküldjük Győrbe, majd Pécsre, majd Szegedre, és onnan végül Debrecenbe. Kicsit sokba kerülne a postának. Dijkstra (azt hisszem Holland matematikus volt, de most hirtelen ??? ) villamosvezetékek elrendezésére kitalált egy algoritmust, amivel legkevesebb vezetékből lehet elektromos hálózatot építeni. Ez lényegében egy gráfon megkeresi a legkisebb súlyú feszítőfát (egyik pontból a másikba a legrövidebb utat, mégpedig minden pontra működik). Vagyis ha összekötjük a postákat, és utána súlyozzuk az éleket a posták közti utazási idővel, akkor egy gráfot kapunk, melyre ha Dijkstra algoritmusát alkalmazzuk megkapjuk a legrövidebb utat két posta között. A routereket ezek alapján konfigurálják, ezzel érik el, hogy minél kevesebb csomagütközés legyen, és lehetőleg a leggyorsabban jusson el csomagunk a partnerhez. Gondolom nem örülnél neki, ha a 2mbites adsl kapcsolattal csak 3 kbyte/sec-el tudnál tölteni, mert körbeutazza a csomag a világot, pedig csak a szomszédnak küldesz egy mp3-at.

Ha már mp3, vagyis zene. Biztos volt már úgy, hogy walkmant hallgattatok és szerettetek volna megmutatni egy számot a haverotoknak. Viszont a szám sztereóban élvezhető, és … na yolvan, a lényeg hogy szükség volt egy jack osztóra. Hálózatoknál is előfordul, hogy hirtelen bekerül egy gép a lakásba, viszont a routeren már nincs több férőhely. Ilyenkor az ember vesz egy switchet, amivel toldhat. Régebben voltak hubok, mostanában már nem kapni, a switch egy intelligens hub. A switch tudja, hogy milyen gép van a lábánál, a hub nem. A hub minden gépnek elküldi az üzenetet ami ő rá van kötve, a switch csak bizonyos lábán. Röviden ennyi a különbség. A probléma akkor áll fenn, ha nagyobb hálózatunk van, tele switchekkel, meg hálózatokkal, és mondjuk az egyik hálózatnak van csak internet kapcsolata. Előfordulhat ugyanis, hogy kör alakul ki, és ekkor egy csomag el kezd cirkulálni a hálózaton, majd bizonyos idő után persze inaktívvál válik és meghal, de addig is lassítja az adatforgalmat.
Erre használjuk Bellmann-Ford algoritmust, ami szintén egy feszítőfát állít elő, ezzel a switchek kimenő ágait tudjuk korlátozni, ezzel küszöböljük ki a köröket.

Rails application opens ports by its own server engine (you should only call script/server in the project to start a process on the 3000 port), or you can use other software, for example Mongrel (there is another solution with fastcgi, but the restart is complicated). You can specify the number of the listening ports and the number of the parallel threads to response to the requests. You need to bunch these ports to port 80, so you need a server that proxies the requests coming on the port 80 to the Rails processes. So briefly, you need a web server to proxy, and Mongrel processes which run the Rails applications.

Currently the Passenger module to Nginx and Apache skips the application server part of the previous process (the Mongrel processes), and creates Rails instances directly from the web server, so you should specify only your application’s public directory in the web server’s configuration file, and it works out of the box. So, I have an old active system with the 3-step-process, and there is a better solution that I would like to support and would be comfortable in the future.

I was sitting on a fence how I should solve this problem, how I could separate similar environments to different scopes. Building a virtual server park could be an alternative, but I don’t want to run a lot of apache web servers and ssh daemons concurrently. My other problem was ssh protocol doesn’t not support virtual hosts, and since I haven’t got different IP addresses to each virtual server, I should support ssh access on different ports, which I don’t want.

I tried to make a solution for this hosting problem, and finally the result was different chrooted environments for the old and the new version of Rails. I decided to use that kind of separation for all bigger components, like database services, name server, mail server, developer part, so I would call these bigger environments as racks. Backuping files is very important on servers, therefore I needed to found a solution for that problem also, so I’d like to show some tricks which is very comfortable later.

Receipt:

You will need squashfs and aufs first. Aufs is an union filesystem in kernel space (using postfix caused some aufs ooops in kernel, so I recommend to use fuse-unionfs in this case, the problem it’s running in user space, so the context switches cause performance decrease)

First create a minimal chroot environment that will be extended to service oriented rack. Using mksquashfs, we pack it to an image file that will be the hibernated service. Using aufs, make a merge of the read only image file’s content with a writable directory on the file system. All changes in this rack appear in this writable directory, so when you want to make a backup, you have to save only the writable partition. So the goal is each read only image (created by mksquashfs) contains (only) the whole software environment for a service (like mail-server, database-server), and each more file like configurations, created and modified files will be on the writable partition.

My directory structure is the following:

/racks - all the data of the racks
/racks/iso - iso files which contain the services
/racks/readonly - readonly directories mounted by loopback
/racks/readwrite - modified files
/racks/active - merged readonly and a readwrite directories
/var/share - shared files like unix sockets, common log files...
/racks/share/dev - dev directory into chroot environments

Building steps:Let webserver-1.0.iso is the web server environment. Building racks will be in the next part of this thread, till then you can create chroot environment with debootstrap in Debian or Ubuntu (of course it won’t contain webserver components), or download a Gentoo stage 3 archive.

debootstrap --variant=minbase lenny /tmp/chroot_base
mksquashfs /tmp/chroot_base /racks/iso/webserver-1.0.iso

webserver-1.0.iso is in the /racks/iso directory, and you can burn it to a disc for backup. According to the previous directory roles, you need to create the corresponding directories in the rack structure, so you need

/racks/readonly/webserver
/racks/readwrite/webserver
/racks/active/webserver

Mount the image to the readonly directory:

mount -o loop,ro /racks/iso/webserver-1.0.iso /racks/readonly/webserver

Merge it with the readwrite part to the active directory

mount -t aufs -o br=/racks/readwrite/webserver=rw:/racks/readonly/webserver=ro none /racks/active/webserver

After merge is ready, we have to mount the default directories:

Mount /proc

mount -t proc none /racks/active/webserver/proc

Mount /devmount -o bind /racks/share/dev /racks/active/webserver/dev

Mount /var/share

mount -o bind /var/share /racks/active/webserver/dev

Mount /home

mount -o bind /home /racks/active/webserver/home

And finally, jump to the rack with

chroot /racks/active/webserver

I have a script that runs these steps, starts daemon applications after the mount process, when you want to stop the rack it stops all daemons and processes and unmount the directories in the right order.When you have a new upgrade from a software (for example when a new Nginx or Apache is released), just extract the current image to somewhere, upgrade the software in the new one, test it by chroot into it, when everything seems to be good, make a new iso with squashfs and edit your script to use webserver-2.0.iso instead of 1.0. The writable layer is the same, and if something goes wrong, you just back up to 1.0.

In the next part I’m going to show how you can create environments from scratch, which contain only that software you need.