kgadek/amber

Projekt inżynierski Konrada Gądka i Michała Konarskiego.

"Master branch"

"Develop branch"

                                                      bbbbbbbb                                                      
               AAA                                    b::::::b            EEEEEEEEEEEEEEEEEEEEEE                    
              A:::A                                   b::::::b            E::::::::::::::::::::E                    
             A:::::A                                  b::::::b            E::::::::::::::::::::E                    
            A:::::::A                                  b:::::b            EE::::::EEEEEEEEE::::E                    
           A:::::::::A            mmmmmmm    mmmmmmm   b:::::bbbbbbbbb      E:::::E       EEEEEErrrrr   rrrrrrrrr   
          A:::::A:::::A         mm:::::::m  m:::::::mm b::::::::::::::bb    E:::::E             r::::rrr:::::::::r  
         A:::::A A:::::A       m::::::::::mm::::::::::mb::::::::::::::::b   E::::::EEEEEEEEEE   r:::::::::::::::::r 
        A:::::A   A:::::A      m::::::::::::::::::::::mb:::::bbbbb:::::::b  E:::::::::::::::E   rr::::::rrrrr::::::r
       A:::::A     A:::::A     m:::::mmm::::::mmm:::::mb:::::b    b::::::b  E:::::::::::::::E    r:::::r     r:::::r
      A:::::AAAAAAAAA:::::A    m::::m   m::::m   m::::mb:::::b     b:::::b  E::::::EEEEEEEEEE    r:::::r     rrrrrrr
     A:::::::::::::::::::::A   m::::m   m::::m   m::::mb:::::b     b:::::b  E:::::E              r:::::r            
    A:::::AAAAAAAAAAAAA:::::A  m::::m   m::::m   m::::mb:::::b     b:::::b  E:::::E       EEEEEE r:::::r            
   A:::::A             A:::::A m::::m   m::::m   m::::mb:::::bbbbbb::::::bEE::::::EEEEEEEE:::::E r:::::r            
  A:::::A               A:::::Am::::m   m::::m   m::::mb::::::::::::::::b E::::::::::::::::::::E r:::::r            
 A:::::A                 A:::::A::::m   m::::m   m::::mb:::::::::::::::b  E::::::::::::::::::::E r:::::r            
AAAAAAA                   AAAAAAAmmmm   mmmmmm   mmmmmmbbbbbbbbbbbbbbbb   EEEEEEEEEEEEEEEEEEEEEE rrrrrrr            

Projekt "Amber"

Projekt inżynierski Konrada Gądka i Michała Konarskiego. Składa się z

• mediatora (Erlang)
• sterowników urządzeń (C/C++)
• aplikacji klienckich (Erlang, Java)

Projekt jest w stadium rozwojowym. Wszystkie flagi debugowania są włączone.

Dwa słowa o testach.

Wow. Istnieją.

Wymagania

Potrzebne są:

• kompilator GCC. Clang być może sobie poradzi,
• Erlang w wersji R15B lub R16B.

Uwagi: Erlang z paczek Ubuntu nie zawiera np. programu to_erl -- polecam zainstalować paczki ze strony Erlang Solutions.

Pierwsza kompilacja

1. make all # ściąga zależności, kompiluje projekt i sterowniki
2. make test # testy

Następne kompilacje

• make # kompiluje zmiany wprowadzone do mediatora (amber) i klienta (amber_client)
• make drivers # kompiluje wszystkie sterowniki
• make roboclaw_drivers # kompiluje konkretny sterownik

Uruchamianie

W skrócie: serwer zwykle będzie działać wiecznie (w wypadku awarii sam się zrestartuje), klient jest /jednorazowy/.

Serwer

1. Uruchom skrypt ./start_amber. Uruchomił się w tle. Logi uruchomieniowe są w katalogu log.
2. By podłączyć się do konsoli erlanga, wywołaj polecenie to_erl pipes/ (slash na końcu jest potrzebny).
3. By odłączyć się od konsoli: Ctrl-D.
4. By zamknąć erlanga: a. Podłącz się do konsoli i wywołaj polecenie q(). (razem z kropką na końcu). b. killall heart.

Klient w Erlangu

./start_client

Klient w Javie

Znajduje się w subrepozytorium. By je pobrać, należy wydać polecenia:

1. git submodule init -- zainicjowanie konfiguracji
2. git submodule update -- ściągnięcie podrepozytoriów'

Można też zwyczajnie sklonować repozytorium mjkpl/amber-java-clients.

Git workflow

Warto przeglądnąć artykuł A successful Git branching model. Poniższy obrazek prezentuje koncept. Może wydawać się to skomplikowane, ale takim nie jest. Opcja --no-ff została domyślnie ustawiona na branche master oraz develop.

amber's Issues

Usunąć kernel/stdlib z zależności aplikacji

Bardziej wygodne podawanie argumentów

Zmienić stałe na parametry pobierane z env.

Atomiczność operacji na mnesii w router:handle_cast({send_msg...},_,_)

Jak zwykle, mnesia:transaction/1 jest zbyt drobnoziarniste, należy otoczyć całe get_or_create

Update config

http://paste.org/59568

Naprawić memory leak

Nigdy nie czyścimy danych o starych klientach. Jest to problem w wypadku:

1. klientów łączących się po UDP (o ile nie zaklepiemy heartbeat);
2. klientów, którzy zmieniają często adresy IP / otwierają nowe gniazda zamiast używać starych;
3. robota, którego soft długo nie jest restartowany.

Możliwe rozwiązania:

1. przejście na TCP/SCTP;
2. napisanie nowego connectora (Erlangowego modułu z behaviour: router);
3. dodanie timestamp do informacji w bazie, okresowe czyszczenie bazy (aka GC którego nie chcemy, bo to nam popsuje soft-real time);
4. pakiety keepalive w UDP pozwoliłyby uzyskać to, co {keepalive, true} daje w TCP. Patrz: #9 .

Umożliwić bezpośrednie łączenie się klienta z mediatorem

Porządek z repo

Wszystkie sterowniki i klienci.

Behaviour dla odseparowanych od amber_client modułów klienckich

Ukończyć API dla klientów

Separacja stargazer/roboclaw od amber_client

Reakcja VM na śmierć appki

Patrz:

• Application started with: application:start(AppName, temporary)

  ** Ends normally: Nothing special happens, the application has stopped.
  ** Ends abnormally: The error is reported, and the application terminates without restarting.

• Application started with: application:start(AppName, transient)

  ** Ends normally: Nothing special happens, the application has stopped.
  ** Ends abnormally: The error is reported, all the other applications are stopped and the VM shuts down.

• Application started with: application:start(AppName, permanent)

  ** Ends normally: All other applications are terminated and the VM shuts down.
  ** Ends abnormally: Same; all applications are terminated, the VM shuts down.

Atomiczność operacji na mnesii w amber_sup:init/1

Zbyt drobnoziarniste mnesia:transaction/1.

Directories refactoring

settings.conf should be in more accessible directory, not deep in apps/amber/src.

Drivers and clients should also be in their own directory tree somewhere in root directory, not in apps/amber.

Two-way handshake

Driver wysyła swój PID, w odpowiedzi mediator wysyła konfigurację (być może pustą: <<>> ).

Uwaga

Trzeba się zatroszczyć o to, by nic innego wcześniej nie poleciało. Zagwarantować wykonanie inicjalizacji w init/1 wydaje się rozsądne.

Pakiety keepalive

Mediator wysyła okresowo (co 1-2s?) pakiety do klientów i driverów oczekując odpowiedzi. Jeśli jej nie dostanie w określonym czasie to uznaje, że klient czy driver nie działają. Wykonuje w takim wypadku odpowiednie operacje.

Uwagi

Co to znaczy " odpowiednie operacje " ? Co ma otrzymać driver po śmierci klienta ? Które drivery powinny to otrzymać ? Co, gdy driver umrze -- czy klienci powinni o tym wiedzieć?

deregister_receiver

Kilka wniosków z lab 03.01.2013

Dwie rzeczy:

1. Ignorować to, co leci do nieistniejącego urządzenia / klienta
2. zbadać, czy restart routera wymaga restartu sterowników
3. Komunikaty błędów?

Connector przez TCP

Szkic serwera TCP już w c66d32d

Zależności po protokole git:// → http://

Localization → Location

Profiling mediatora

amber_client nie przez UDP ale lokalnie