[ noctua @ 08.07.2004. 09:50 ] @
Pozdrav svima!

Dobio sam zadatak da prepravim postojeci DOS program (radi pod Win95 na 486-ci) za nadgledanje telefonske centrale Panasonic D1232, odnosno, da napisem isti/slican "program" koji bi radio na nekom linuxu...
WorkFlow je: Centrala salje podatke (datum, vreme, lokal sa kog se zove, broj koji se zove i duzina trajanja razgovora) na seriski ili pararelni port a stampac ih preuzima i stampa.
Stari program je napisan kao servis (da bi radio, mora da je otvoren DOS prozor stalno) i glumi stampac koji podatke belezi u fajl.
"Program" bi trebalo da pokupi podatke (datum, vreme, lokal sa kog se zove, broj koji se zove i duzina trajanja razgovora) sa seriskog ili paralelnog porta i upise to u bazu odakle bi se ti podaci dalje koristili.
Iz sasvim opravdanih razloga (pristup iz lokalne mreze, pristup odredjenim korisnicima sa spoljnih mreza, ko pristupa, sa koje mahine, sta radi sa podacima,...) reseno je da se ide preko web portala.
Portal je spreman (radjen u LAMP okruzenju) ostalo je samo da "progovorim" sa portovima.
Nesto mi se programira u C-u (zapravo, nisam toliki poznavalac C-a i vise bi napravio stete)

Ono sto me zanima je:
1. Da li se u perlu moze otvoriti seriski ili paralelni port i kako to da izvedem?
2. Da li je moguce napraviti nesto sto bi se ponasalo kao demon (podizalo prilikom bootovanja i radilo u pozadini non-stop) a da pri tom ne zauzme previse resursa?
3. Palo mi je na pamet da iskorisim nesto tipa:
cat /proc/ttyS0 posto je linux u pitanju,
ali nisam siguran kako da tretiram "taj fajl"; sta posle da radim i da li ce se izgubiti neki podatak (ako u nekom slucaju 100 korisnika odjednom krene da telefonira) a nisam u mogucnosti da testiram tako nesto na duzi vremenski period.

Da li je neko radio sa portovima u perlu i kakva su mu iskustva?
Da li neko ima slicna iskustva?
Zapravo, ima li neko iskustva sa telefonskim centralama?


Unaprad zahvalan!

[ alex @ 08.07.2004. 10:49 ] @
A nije ti palo na pamet da pre svega toga malo procesljas Google?

Drugi link na listi koju ispise google je ovaj - Log Serial Port Data to a Specified Logfile, uz pomoc perla.. Sa sve source-om to get you started..

[ noctua @ 08.07.2004. 14:13 ] @
Pozdrav!
Iskreno receno palo mi je na pamet i trazio sam ali nisam za PERL vec za PHP :-(
Priznajem da sam kriv! Moja greska! :-((

Pogledao sam kod, ali me i dalje interesuje, kako se to ponasa u real-time radu, pogotovu sto bih ja to prepravio da sve pise u bazu a ne u fajl...
Naime, postoji realna mogucnost da se u nekom trenutnku pojavi pozamasna kolicina podataka na portu, pa malo cvikam da se ne pogubi neki dok vrsim upis u bazu. Mislim, da se ne desi nesto tipa "buffer overrun" ili neka slicna sitnica...
Mozda je ovo sto pitam glupo ali nisam preterano vican perlu i ne poznajem bas najbolje kako bi se sve to ponasalo u ovakvoj situaciji...

U svakom slucaju, HVALA.
Pomoc mi je mnogo znacila
[ zsteva @ 08.07.2004. 21:37 ] @
imam ja neka iskustva, ali za si2000 (ili je mozda bila neka serija pre si2000),
dodushe to je bilo davno...

uglavnom sve shto ti treba moze da se uradi, najblje da deamon parseruje na licu mesta
i puni neku tabelu.

btw, moze i php, verovatno moze i bash/awk.

naravno web portal perl ili php...
[ Free_Sex @ 13.07.2004. 14:34 ] @
Nisam neki expert. Pogotovo ne za linux. Ali koliko se secam negde iz specifikacija ili slicno serijskog (paralelnog) porta. On se sam brine oko bufffer overflow problema.

Dakle on puni baffer sa onime sto prima. U isto vreme ti ga praznis, i sve je lepo dok ga ti brze praznis nego sto ga on puni. A kad on vise ne bude imao mesta. Trabalo bi da prekine siglan ready to receive (ili kako se vec tacno zove).

Naravno, druga strana trebala bi tada da prekine sa slanjem. Kazem trebala bi, nikad se ne zna.

Dakle koliko sam ja sve to skapirao, ti ne treba da se previse brines oko toga. A posto ce perl program raditi non-stop. Dakle bice iskompajliran jednom po pokretanju, ne bi trebalo da te muci brzina.

Javi sta si uradio. Pa da okacimo na sucess stories na perl.com :)
[ sspasic @ 13.07.2004. 18:49 ] @
Citat:

Dakle on puni baffer sa onime sto prima. U isto vreme ti ga praznis,
i sve je lepo dok ga ti brze praznis nego sto ga on puni. A kad on vise ne bude imao mesta.
Trabalo bi da prekine signal ready to receive (ili kako se vec tacno zove).


Ovo važi samo ukoliko se koristi handshaking. A i tada zavisi od toga koliki
je send buffer na strani centrale.

Ukoliko se handshaking ne koristi na samom čipu u PC-u postoji buffer, obično
veličine 16b, yavisno od čipa.

U svakom slučaju, ako bi ti petlja:
1. Pročitaš slog sa serijskog porta
2. Upišeš slog u bazu
3. goto 1
gubila bajtove, možeš da stvar rešiš pomoću producer/consumer šablona, sa
dva procesa od kojih jedan samo čita serijski port i sve pročitano smešta
u buffer (producer) i drugi koji bafer čita, parsira slogove i upisuje u bazu (consumer).

Producer i consumer mogu da budu niti (threads) kada buffer štitiš mutex-ima ili procesi gde buffer kreiraš i štitiš IPC objektima. Ako se odlučiš za procese, buffer možeš da napraviš i kao direktorijum na disku, gde producer radi na sledeći način:
1. Pročita slog sa serijskog porta
2. U direktorijumu kreira novi fajl sa jedinstvenim imenom (prefix A + timestamp + random), u njega upiše slog sa serijskog porta i zatvori fajl.
3. preimenuje fajl u B-timestamp-random
4. goto 1

Consumer radi ovako:
1. Pročita iz direktorijuma spisak fajlova koji počinju sa B (dakle kompletni slogovi)
2. Sve nađene fajlove pročita, parsira i prepiše u bazu.
3. sačeka 1s
4. goto 1

Drugom procesu možeš i da sniziš prioritet.

U svakom slučaju ovo je komplikovaniji način od proste petlje u jednom procesu i
više opterećuje procesor i disk, ali su operacije bolje raspoređene i smanjuje se
mogućnost da se nešto zagubi kada velika količina podataka nagrne na serijski port.
[ Free_Sex @ 14.07.2004. 10:10 ] @
Da nije to sa diskom malo zastarelo. Mislim i ja bi se toga prvo setio. Ali ...

Ali imas sada neki IPX modul za perl. Koji ti sluzi za komunikaciju medju procesima, deljenu memoriju i sl.

Taj IPX ti je ustvari standard za medjuprocesnu komunikaciju (ako sam ja dobro skapirao), a perl-ov modul se zove nekako slicno. Potrazi na www.cpan.org

A ovo resenje bi trebalo i da manje zauzima procesor i skoro nista disk (disk bi zauzimala sama baza podataka) tako da je to cini mi se bolje resenje.

I naravno konekciju sa bazom otvoris na pocetku programa. I jednom odradis prepare sa placeholderima (znas ono sa ? ). I posle samo kazes u petlji execute (i onda lista vrednosti).

Mislim da neces imati problema sa time. Trebalo bi da ti to radi kao sat i bez vise procesa.

Inace ako oni nisu koristili handshake za komunikaciju, zivo me zanima kako su to onda resili pod windows/dos-om ... koji moze samo jedan proces da izvrsava u jednom trenutku.
[ ivanhoe @ 01.08.2004. 02:36 ] @
mogao bi i da naprosto ima jedan skript koji pishe u logfile sa serijskog porta i drugi kome je na STDIN pipe-ovan tail -f logfajla, i koji naprosto ima while(<>) petlju u kojoj insertuje $_ u bazu...

poz,
ivan
[ noctua @ 04.08.2004. 11:41 ] @
Pozdrav!

Pre svega HVALA svima na dobrima idejama i savetima!
Stvar je resena samo ja nisam imao vremena da napisem "report" :)
Free_Sex je predlozio modul, ali imao sam problema sa instalacijom istog tako da sam se odlucio za izvesnu modifikaciju sspasic-evih i ivanhoe-vih ideja.
To izgleda ovako:
Jedan Perl "program" radi kao deamon i non-stop slusa COM port. Sve sto naidje belezi se u log fajl.
Drugi Perl "program" se pokrece cron-om na svakih 10 minuta i cita (kopira u fajl koji se obradjuje) log. Procitani podaci se smestaju u bazu i u posebni dnevni log.
Cron i logrotate odradjuju ostatak posla za potrebe backup-a...
Ovako ima i rezervnih kopija podataka (dnevni, mesecni, godisnji) sa centrala u slucaju da nesto krene po zlu.

Prvobitna ideja je bila da se sve direkto upisuje u bazu bez pisanja po fajlsistemu ali imao sam dosta problema sa odzivom sistema. Kako hardver koj je bio na raspolaganju i nije reprezetativan, (a pre ce biti da i moje znanje perla nije reprezentativno:-), vreme odziva baze je bilo dovoljno sporo da promakne po neki poziv ili da se maxina toliko zagusi da je pristup sajtu neprihvatljivo spor... Narocito kada se nadju 3-4 korisnika odjednom koji nesto pretrazuju po tabelama ili generisu PDF report na osnovu pretrage...
To je doslo do izrazaja kada sam ubacio u bazu 4-godisnji back-up. Tabele gde se beleze "pozivi" su narasle na po 800-900 hiljada slogova po godini...
Zato je Cron postavljen na 10 minuta, da maxina ima vremena da se izbori sa veselim (bes)korisnicima... a i navalica na telefon je u radno vreme (u proseku od 7-16h) dok se sajt najvise koristi od 11-18h... cini mi se da je to neko kompromisno resenje...

Mozda ovo i nije najsrecnija realizacija, ali, kada se uzme u obzir hardver na kom se to vrti i skromna kolicina mog perl znanja... zasada, to radi kako treba...

A sad malo marketing: Oce neko to da kupi? Treba li nekom softver za panasonic centrale? :-)))))))))
Shega ba, shega!
Razmisljam da ovo sto sam napravio postavim negde za free download ali nisam siguran da nekoga tako nesto interesuje, narocito kada se uzme u obzir cinjenica da sa centralom dobijes Windows softver koji isto to radi...

Eto, u svakom slucaju, HVALA jos jednom na dobrim savetima i idejama!

PS. Kako je ovo gotovo, sada apetiti rastu. Da li neko zna da li je moguce dinamicki pokupiti od provajdera (u ovom slucaju PTT YU) cene razgovora u zavisnosti od doba dana; zone poziva; trajanja razgovora? (Postavicu ovo pitanje na i na PHP forumu)
[ VRider @ 04.08.2004. 19:32 ] @
Ti razgovor ne placas provajderu, nego Telekomu. Provajderu placas fixno vreme. Telekom ima cenonik, koji mozes da preuzimas sa njihovog sajta (www.telekom.yu) pomocu alata iz modula LWP i HTTP, ali ne vidim nekog razloga da to radis, jer su cene takve kakve su vec dugo vremena. Lakse ce biti na napravis jednu tabelu koju ces sam da popunis (nema 20 redova), i ako se cene promene, da je rucno i izmenis.
P.S. Zasto je tu uopste portovano na linux?
[ ivanhoe @ 12.08.2004. 17:20 ] @
Ako ti je vec frka oko resursa i brzine mozda da ne pokreces taj drugi perl iz crona, nego da ti bude stalno upaljen, tako stedish procesorsko vreme za paljenje perla i kompajliranje scripte svakih 10 minuta, plus ako koristis DBI(a verovatno koristis) za pristup bazi, mogao bi da drzis otvorenu vezu prema bazi, jer kreiranje veze guta najvise vremena..znaci samo kazes perlu da odspava 10 minuta i da onda ponovi operaciju...