W dniu 08.02.2016 20:05, Jaroslaw Dziubek napisał(a):
Na początek - czytałeś nasze wypociny? :)
Tak - ogólnie to ciężko się do czegoś przyczepić ;-)
[Monday, 08 February 2016], Tomasz Chiliński napisał(a):
- netnodes (węzły):
- dodanie ownerid (jeśli >0 - wezęł u klienta)
- netelements:
- typ: aktywne urządzenie/pasywny obiekt/pasywny kabel/(opcjonalnie:
pasywny splitter)
- netnodeid obowiazkowo (i stad bylaby brana lokalizacja)
- producent/model/nr seryjny/projekt
To zapewne miałoby być do netdevices i netcables? Jeśli również do netcables to brakuje powiązania w netcables...
Przeoczenie :)
- netelemcables (dotyczy kabli)
To po prostu można nazwać netcables.
Kwestia nazewnictwa ;)
- medium: optyka/miedź
- rodzaj: jednotubowy/wielotubowy/KLD/splitter (opcjonalnie)
- pojemność: ilość żył (jeśli tu damy splitter to ilosc zyl w
ukladzie "1:32")
- długość
- obiekty: źródłowy i docelowy
- netelemports (dotyczy urządzeń)
... a to netdevports
A moze po prostu netports?
Tak, netports będzie faktycznie chyba jeszcze lepiej. Choć z drugiej strony czy nie mogą istnieć porty inne niż urządzeń sieciowych? A propos netports - słownik technologii łącza danych można powiedzieć, że już mamy: https://github.com/lmsgit/lms/blob/master/lib/definitions.php#L338
- netelement_id
- etykieta
- port_uplink (0/1)
- typ portu (100BaseT, SFTP+)
- rodzaj złącza (UTP, simplex SC/APC - jeśli null to port bez
wkładki)
- technologia (Ethernet, xWDM, xPON)
- prędkość up/down (aczkolwiek to można brać z technologi)
- netradiosectors (dotyczy urządzeń radiowych)
- netelement_id
- identycznie jak jest teraz (technologia, zasieg, kąt, itd)
- netelemparams (dotyczy obiektów pasywnych)
- netelement_id
- typ (typ złącza dla pola komutacyjnego - SC/APC itp lub
"nierozłączalne" dla tacki spawów)
- nr w obiekcie (tacka#1, port#12)
- pojemnosc (2 dla rozłączalnych, >2 dla tacek)
- netelemsplitter (jesli w netelements)
... netsplitters
:)
- ilosc portow_in
- ilosc portów_out
– netconnections:
Zakładam, że tu chodzi o łączenia elementów kablowych? Pewnie założenie było takie, żeby i zastąpić tym netlinks (swoje zdanie na ten temat podałem niżej)?
Tak - być może nie od razu (odpisze poniżej)
- rodzaj źródła (urządzenie/obiekt/kabel/splitter)
- id źródła
- rodzaj celu ((urządzenie/obiekt/kabel/splitter)
- id celu
- długość (opcjonalne)
- plik z pomiarami (opcjonalne np. dla spawów)
gdzie id_zrodla/id_celu to albo: - id_portu w urządzeniu/obiekcie/splitterze - id_kabla:nr_tuby:nr_włókna dla simplex - id_kabla1:nr_tuby1:nr_włókna1|id_kabla2:nr_tuby2:nr_włókna2 - dla dumplex
netlinks zostawiłbym raczej tak jak jest, bo to połączenia logiczne. Potrzebne jest za to wiązanie na portach połączeń logicznych z połączeniami fizycznymi. Nie warto pakować wszystkiego co się da do netconnections, bo taka uniwersalizacja spowoduje mocną komplikację zapytań sql oraz konieczność tworzenia złożonych aktualizacji schematu bazy danych. Jeśli potem uznamy, że jednak warto zunifikować obecne netlinks z netconnections to będzie to do zrobienia.
Tak naprawdę w mojej koncepcji netlinks wylatuje wogole. Połączenie logiczne w rozumieniu tego co jest w tej chwili w LMS nie ma najmniejszego sensu - ficzyne połączenie między dwoma urządzeniami sieciowymi aktywnymi tak naprawdę będzie w netconnections, natomiast pozostałem parametry połączenia (technologia, prędkość) będzie pobierane z definicji portów w których dane połączenie jest zakańczane
Przy takim założeniu od razu wszystkim narzucasz konieczność opisywania pełnych traktów sieciowych, a to może być upierdliwe w przypadku, gdy ktoś nie bawi się w inwentaryzację warstwy fizycznej. Poza tym ktoś może chcieć oddać niekompletny raport, ale chroniący w dużym stopniu przed szykanami ze strony UKE...
- jeśli np. definicja portu będzie mówić że to port typu UTP Base100TX
to wiadomo, ze prędkość połączenia to 100Mbit FD (opisywałem to parenascie maili wcześniej). Odpowiednio definiujac porty spokojnie mozna ogarnac to "z automatu".
Jarek