Várom akkor az ötletek ahhoz, hogy Ti hogyan oldanátok meg azt a helyzetet, ha mondjuk van 2-300db. olyan helyszínetek ahol nincs térerő, új vezetéket behúzni nagyon költséges, de van elektromos áram, és egy folytonos acélszerkezet cikázik össze-vissza közöttük.
Elárulom az ötletet egy kalandfilm adta, ahol a bányászok úgy beszélgettek a központtal, hogy a csille sínjéhez csatlakoztatták a headset-jüket... ezért reménykedek, hogy ezt ténylegesen is meg lehet ezt oldani.
Ha sokat gondolkodsz rajta, szerintem újra fel fogod találni a távírót! :D
Gyanítom, hogy az alapfeladat eleve máshogy is megoldható. Tisztára úgy néz ki ez a feladat, mint amikor valaki elkezd tervezni valamit, de megakad. Ahelyett, hogy az eredeti problémát közölné, inkább azt a fázist mondja el, ahol elakadt.
Esetleg meg lehetne tudni hogy mi okból lett kizárva az összes "hagyományos" távközlési mód?
Amúgy az a rengeteg vas elég drágává teszi a projectet. Persze elég nagy cég lehet, aki saját telephelyén ekkora távolságokon saját "kábelt" tud fektetni.
Ha már érdekel a nem hagyományos adatátvitel, nézz rá az RFC 1149-re.
A két kilométeres csövet takarhatja az útján földhányás, elég ha a vége a célállomásnál kijön a felszínre.
De ha zavar, hogy kijön (meglátják? ellopják?), akkor végződhet földalatti aknában is, ahol az indiánoknak asztalt, ágyat is elhelyezhetsz (a 24-órás váltás pihenőjét megoldandó). Ajánlott olvasmány a veszprémi szikla története.
Azzal a 300 bauddal bármelyik távgépíró elbánik, még az imént feltalált koaxkábelemmel is.
Ha valaki komolyan is tudja venni a feladatot és időt és energiát is tud rá áldozni (persze honorálás fejében) akkor az e-mail címem nyilvános.
De mint mondottam az acélszerkezetnek kell a jelet vinnie. Ja és nem 20kbájt/s hanem 20kbájt/perc. De inkább úgy írom, hogy napi 20-25Mb adatot kell forgalmazni.
(Jó ötlen lenne a kopgtató indián is, de akkor azt kell megoldani hogy pár méter földtakarás alatt is kopogtasson a nap 24 órájában. )
Nem találtam más fórumot, ezért ide írok, hátha ti tudtok segíteni vagy ajánlani valakit / valamit.
Kétirányú adat kommunikációt kellene megoldani földbe fektetett acélcsövek, vagy vasúti sinek, vagy egyéb folytonos acélszerkezetet segítségével.
Egy központnak kellene kommunikálni egyesével több 1-2 km távol lévő alállomással is. Az elvárt adatfolyam sebessége kb. 20kbájt/s.
Hogy az adatok milyen módon futnak az acélszerkezetben az teljesen mindegy lehet pl.: elektromos, vagy akár ultra vagy infrahang is. A lényeg, hogy A-ból átmenjen B-be.
WIFI, GPRS, és egyéb "hagyományos" adat továbbítás nem érdekel!
"Magam írtam egy progit, ami x időnként berántja a logokat és bizonyos dolgokat bemásol egy állományba, amit nézegetek, elég fapados megoldás, de használható, bizonyos esetekben meg emilben "riaszt"."
Én is írtam egy hasonlót. Annyi különbsééggel, hogy pl. egy Linux szerveren folyamatosan szemmel tudja tartani a logokat. Akár riaszthat is, de adott esemény bekövetkezésekor bármilyen programot vagy scriptet indíthatsz vele.
Ha érdekel valakit, akkor kirakok egy - ilyen kisebb feladatokra ingyenes, demó verziót.
Alapvető ARP kérdésem volna, Windows 7 és Windows XP oprendszereken néztem az alábbiakat.
Törlöm az ARP táblámat:
arp -d
WinDump (ugyanaz mint tcpdump csak windowsra) segítségével lementek egy ARP request csomagot:
windump -c 1 -w arp_req.pcap -t arp
Generálok egy ARP requestet (ki a gateway?):
ping index.hu
Megvan az ARP request csomagom (arp_req.pcap fájlban).
arp -a
A gateway belekerült az ARP táblába. Ismét törlöm az ARP táblát:
arp -d
Az ARP request csomagot kiküldöm a bittwist utility segítségével és azt várom, hogy válaszol a gw és ismét bekerül az ARP táblámba a gw mac címe:
bittwist arp_req.pcap
A Wireshark szerint ki is ment a request, sőt, be is jött a reply a gatewaytől, teljesen ugyanolyan csomagok, mint amik a ping hatására keletkeztek, tehát az ARP táblám nyilván frissült...
arp -a
... de sajnos az ARP táblám üres.
Kérdésem: miért nem frissül az ARP táblám, mi kell még hozzá? Van valami oprendszer vagy alkalmazás szintű réteg, ami az ARP táblát írja és ha "csak úgy" megy a request és jön a reply az nem elég?
Hát úgy tűnik, hogy nem kábelhiba. Kimérték jel adó-vevőkkel , hogy nincs-e szakadás, vagy zárlat, de arra jutottak, hogy nincs.
Viszont a tünetek maradtak. :-)
Az alhálón található gépek között zavartalan a kommunikáció, így talán nem a switch hibás.
Írtam a fő rendszergazdának, hogy tegyen már elérhetővé nekem egy gépet a belső hálón egy másik alhálózaton, hogy azzal is kipróbáljam az adatforgalmat.
Ha ott nem jó, akkor majdnem biztos a kábelsérülés - gondolom én - de ha jó, akkor talán a proxy környékén kellene tovább kereskedni.
Ha megoldódik, akkor megírom, hogy mi volt a gond.
Én elsőként a kábeleket tesztelném le, de volt már olyan is, hogy a switch hülyült meg, ilyenkor egy ki-be kapcsolás szokott rajta segíteni. Ha minden gép produkálja oprendszer függetlenül akkor ez biztosan hardver hiba.
Kipróbáltam azt, hogy egy távoli külső gépre (a webkönyvtáramba) felmásoltam egy 1,5 MByte-os állományt. Csont nélkül fölment 1,4Mbit/sec sebességgel.
Ám amikor ugyanezt az állományt visszapróbáltam másolni a saját gépemre, 100 KB-nál úgy elakadt, ahogyan illik az mostanában.
Hát nem tudom! A kábelekhez nem nyúlt senki a legjobb tudomásom szerint.
Bár az OTP-sek most húztak egy új kábelt az automatájukhoz, amely azonos falréseken bújik át, mint a miénk.
A 100-a mit jelent nálad? Hogy jól működik, vagy hogy 100 Mb-es? :-)
