Gisteren als test de gehele subscriber white overhalen ingezet. Echter toen ik s’avonds thuiskwam werkte de MySQL database niet fris meer. Ik kan mij niet meer herinneren dat MySQL bij mij kapot was. Ik ga nu testen door het met stappen op te schalen. Net is 75 Mb bij mij gelukt.
M.i. is de telefoonsynchronisatie vrij simpel:
je trekt subscriber tabel over de lijn. N.B. Ben ik nu aan het testen om het werkend te krijgen.
alle records staan op telemedia GUID.
Je vult eigen info in en zet daarbij GUID om naar jouw peer.
Als je met telefoonboeken op de andere wil synchroniseren stuur je een query met GUID != telemedia en alleen onze informatie komt terug van de peer waarheen je de query hebt gestuurd. Je krijgt na x minuten info terug en merged het met je eigen telefoonboek. Omdat de peers elkaar straks automatisch vinden, kan je dit m.i. makkelijk automatisch laten uitvoeren.
Even uitleggen hoe ik er vandaag inzit. “Subscriber” moet de basis van de peers worden. Ik denk aan om een merge tussen white en pink. Daarbij de info records in eerste instantie weglaten. Mogelijk wel info uit info records halen en deze in basis importeren (email=adres). Subscriber krijgt dus wel meer velden zoals URL, GUID, ip adres van foonsearchd.exe, etc.
Netwerkquery’s geeft best veel mogelijkheden om Subscriber te updaten. Je kan alle peers toestaan om je Subscriber te updaten (deleten, inserten en updaten). Echter je zou ook een bepaalde peer (Peer_X) kunnen valideren om je Subscriber aan te laten passen. Zelfs zou je iets kunnen maken dat een bepaalde peer alleen maar 1 veld mag aanpassen. Als je rechtstreeks van deze peer iets krijgt dan weet je van wie het komt. Bij indirectie (forwarding) zou je mogelijk een soort ticket kunnen invoeren. Je vraagt een ticket nummer van deze peer aan en als deze peer updates stuurt gaat hij query encrypten met je public key. In de query staat ook de voor andere geheime “ticketnummer”. Andere peers kunnen wel een packet simuleren, echter als ze de ticket nummer niet weten dan weet je dat het niet van de update-autoriteit-peer komt.
Doordat Peer_X ook een netwerkquery aan je pc kan stellen, kan hij ook zien hoe iets staat in je database. Hij kan gericht actie uitvoeren om iets wat scheef staat recht te zetten. Het updaten kan dus veel verder gaan dan alleen maar een “update” installeren.
Ook probeer ik wat tabellen te definieren die een relatie met Subscriber heeft. Bijvoorbeeld “news-” en “enquete”-tabel.
Ik heb ook naar Wengo gekeken. Ik zie dat er veel zaken in staan die ik best goed kan gebruiken. Volgende week concentreren op een merge tussen SAFMQ, Wengo en foonsearchd.
Het zippen met http://www.codeproject.com/file/zip_utils.asp werkt erg goed. Ik geef queryresult.dat als naam op van output van de query. Als je meerdere query’s zou hebben, zou je wel voor queryresult?.dat kunnen kiezen. ? geeft de volgnummer van de subquery in het queryblobveld aan.
Ik zag een foutmelding bij de MySQL commando load_file dat de file te groot zou zijn. 100 Mb werkte wel, echter bij 158 Mb kreeg ik deze foutmelding. N.B. Met loadfile laadt je een file in een blobveld.
Vanmorgen aan het testen om de gehele subscriber (417 Mb) over te halen. Op het laatst bij het resenden kreeg ik een foutmelding “MySQL server has gone away”. Hierna MySQL service gestopt, wat een “Server shutdown in progress” foutmelding geeft. Hierna opgestart. Foonsearchd.exe werkt wel door, echter ik heb er niet ingeprogrammeerd dat hij opnieuw een connectie moet opbouwen. Eigenlijk moet ik op de MySQL foutmeldingen goede acties uitvoeren, zoals opnieuw naar MySQL connecten. Het programma foonsearchd.exe wil ik zoveel mogelijk door laten lopen.
RGJ, De resend strategie ben ik momenteel aan het bestuderen en proberen om dat stabieler te krijgen. In het begin leek het veel op regeltechniek. Het ging oscileren i.p.v. gedempt naar eindsituatie te gaan.
Het is mij nu twee maal gelukt om de subscriber_white (417 Mb) over te halen --)
De MySQL server crasht ook niet meer want ik heb de MySQL commando’s load_file() uitgezet.
Geen man overboord want ik gebruik de blobvelden toch nog niet. Het gecontroleerd laten crashen met load_file() biedt wel de mogelijk om foonsearchd zo te maken dat hij werkt als de MySQL server weer terug is.
Ik heb een procedure gemaakt die controleert of alle blocken aanwezig zijn. Deze procedure gaat vanaf Sequencenumber 1 door tot de laatste Sequencenumber (= 815480 bij 417 Mb).
Als hij een gat in de volgorde ziet geeft hij dit direct door. De andere peer stuurt dan ‘direct’ de missende blocks door. Echter hier gaat het wat fout, namelijk de checkprocedure is zo druk bezig dat hij niet alle blocks binnenhaalt. Wat weer tot het uitvoeren van de resend-routines leidt.
De oplossing zie ik twee zijdig.
Gebruik de info die je bij een eerdere missende blockroutine hebt verkregen. Ga dus de vorige geconstateerde gaten checken of ze er nu nog wel zijn. Dus de gaten info niet alleen naar de ander peer sturen maar ook locaal in een database zetten.
Oplossing die wat meer tijd kost is om de verschillende threads verschillende prioriteit te geven. Binnen halen thread de hoogste prio. Iets lager is de thread voor het verzenden van de blocks en een nog lager prioriteit is het checken of alle blocks ook binnen zijn.
Ik wil vandaag beginnen met http://www.codeproject.com/file/fileenc.asp
Mijn bedoeling is om van blowfish inbuild te krijgen, dus geen relatie met libeay32.dll De laatste alleen gebruiken voor (https/ftps) RSA verbindingen.
Sommige libeay32.dll geeft het laden van de blowfish routines waarden nul op, dus de beginpoint van de routines worden niet goed uit libeay32.dll geladen.
N.B. Wget gebruikt libeay32.dll en je wilt geen twee libeay32.dll gaan gebruiken. Of precies moeten aangeven bij welke libeay32.dll hij wel werkt.
De stappen om een netwerkquery op andere peer te draaien en het result weer terug te krijgen op je peer:
senden van de query naar de remote peer
selectie uit database
zippen
encrypten
blocken
senden
recieven
8 ) resenden
mergen
decrypten
unzippen
store, result in blob veld
Wat ik voor mij zie is een tijd-begin, tijd-end per stap. Indien een stap veel langer dan 5 minuten duurt, dan per 5 minuten een record met tijdstip en hoever je al bent.
In de GUI de status kunnen laten zien hoe het met de uitvoering van een netwerkquery staat.
Als je “telefoonboeken” met je eigen subscriber wilt synchroniseren dan stap 13) Synchroniseren invoeren.
Je zou ook in eerste stap een enquete naar een peer kunnen sturen. Je zou dan ook een extra stap moeten invoeren om de enquete in te voeren in de GUI programma. Een voorbeeld zou kunnen zijn dat Albert Heijn je een enquete stuurt, die je wel of niet invult. AH kan zien wat de status is van de enquete. Indien je wel invult dan zal in stap 13) automatisch de resultaten verwerkt worden. Afhankelijk van deze resultaten kunnen ze weer een nieuwe enquete gaan maken. Mogelijk ook specifiek naar peers sturen. Dus een vervolgenquete sturen naar Peers die bepaald iets ingevuld hebben.
Ik kan mij voorstellen dat Albert Heijn de resultaten van de enquete niet gaat publiceren, echter je kan natuurlijk als peer een netwerkquery naar andere peers sturen om een mogelijk ingevulde enquete op te sturen. Andere oplossing zou zijn dat er peers komen die enqueteresultaten verwerken. Je stuurt dan het resultaat naast het naar de AH-server te verzenden ook naar zo’n type peer om een (lopende) poll voor andere gemakkelijk bekend te maken.
Vandaag bezig geweest om te testen of je meer bytes kan versturen dan de UDP-MTU. Daarbij de specifieke code in seperate programma gezet. Ik wil de code even strak maken en daar weer terug in het programma brengen.
Theoretically, the maximum size of an IP datagram is 65535 bytes, imposed by the 16-bit total length field in the IP header (Figure 3.1). With an IP header of 20 bytes and a UDP header of 8 bytes, this leaves a maximum of 65507 bytes of user data in a UDP datagram. Most implementations, however, provide less than this maximum.
Zie ook http://galeb.etf.bg.ac.yu/~vladab/knjige/networking/TCP%20IP%20Illustrated,Volume%20One/udp_user.htm
Als ik boven UDP-MTU 1472 kom zie ik UDP-Fragments packets (=1500 bytes) verschijnen met iptraf. Als je veel grote packets (bijvoorbeeld 65500 bytes) verstuurt dan blijken er weinig aan de andere kant over te komen. Mogelijk verstikt de internetverbinding dan in het fragmenteren van UDP packets. Als je een seconden wacht met het verzenden van de volgende grote packet werkt het wel.
Het is nog best wel een uitzoekwerk wat het optimaals zou zijn. Als je groter packets hebt dan zou mogelijk MySQL sneller zijn om packets op te slaan en aan te bieden aan verzending.
Een ander punt is dat je minder bytes moet aanbieden als de upstream capaciteit is. Bied je meer aan dan weet je zeker dat je UDP-packet kwijt bent. N.B. Ik heb nog wel code om op Windows te checken hoeveel bytes je uitstuurt.
Een UDP-packetje van gnunet heeft een bepaalde recordformaat. In het formaat zit geen “importance” en “priority” veld. Importance zie ik voor mij of je een bevriende peer bent of anderzijds een anonieme (evil) peer bent en alles wat er tussenligt. Met priority geeft de sender aan wat de gewenste snelheid van response zou moeten zijn. Denk hierbij aan batch, online-queries, telefonie, etc.
Vandaag verder met UDP senden en recieven. Ik ga in een aparte project het testen. Als goed werkt dan terugpoorten.
Een leuk project is: http://www.codeproject.com/useritems/HwDetect.asp
Op een USB stick ga ik de privat RSA key zetten. Als je de USB-stick er in doet kan je met bovenstaande project zien dat er nieuwe hardware in is gekomen. Je koppelt dan privat RSA key aan. Je kan dan encrypted mail gaan lezen. Als je op andere pc gaat werken dan doe je USB-stick er in en dan kan je daar je mail weer lezen.
Volgende week naar de Wengo code gaan kijken en proberen aan te gaan zetten.
Vandaag naar UDPMessage gekeken. Ik heb een separate send/receive programma om te testen of het werkt.
Het probleem met oude gnunet UDPMessage is dat je geen info van verzendende peer krijgt. Bijvoorbeeld prioriteit en importance.
Ik denk dat de UDPMessage die ik nu heb bedacht wel goed gaat werken. De huidige UDPMessage is 144 bytes groot. Ik heb ook de hash van publickey van receivepeer (16 bytes) er in gezet. Je kan dan direct zien dat een message niet voor jou is, dus deze kan je gewoon verder sturen.
Als ik de code van de separate programma’s terugpoort kan ik het programma m.i. sterk reduceren in regels/complexiteit. Ik ga de callback’s er uitgooien en blowfish encrypty(*). Gebruik je toch niet, want UDP is andere programma dan TCP en momenteel loopt hoofdprogramma ‘vast’ want komt niet op punt waarhij zou moeten wachten. Het start namelijk met callback achtige iets de service UDP, TCP, etc. op.
De vriendelijke groet Jan Marco
P.S. (*) Encrypty (zoals blowfish) breng ik er wel weer in, echter ga ik uit andere projecten halen.
Ben bezig om naast het protocol te veranderen ook hash te upgraden ripe160 (32 asci karakters) naar SHA512 (104 asci karakters). De hash wordt gebruikt om een peer te identificeren. Het is de hash van de public key. Met SHA512 krijg je een grotere “adresspace” als met Ripe160, dus minder snel collisions met andere peers.
Daarnaast ga ik ook zoveel mogelijk (niet gebruikte) code er uitgooien.
Ik hoop dat het volgend weekend minder warm is om lekker verder te werken --)
Ben momenteel bezig om foonsearchd.c op te schonen. Al 10000 regels weggegooid.
Ik hoop dat het van het weekend weer gaat werken, want ik ben ook stevig aan het verbouwen geweest.
hash heb ik veranderd.
receive/send tabel veranderd.
protocol aangepast. Naast importance, priority velden ook iets ingebracht dat je Peeridentity van te ontvangen peer er in opneemt. Je kan nu een 65 kbyte UDP packet met 2300 PINGS naar een peer sturen en deze peer gaat het niet verwerken, echter proberen door te sturen naar de peer waarvoor het bericht bestemd is.
Volgende week ga ik subscriber vullen en dikke van dalen als applicatie er proberen onder te hangen.
[quote=“alkema_jm”]Hoi RGJ,
Een leuk project is: http://www.codeproject.com/useritems/HwDetect.asp
Op een USB stick ga ik de privat RSA key zetten. Als je de USB-stick er in doet kan je met bovenstaande project zien dat er nieuwe hardware in is gekomen. Je koppelt dan privat RSA key aan. Je kan dan encrypted mail gaan lezen. Als je op andere pc gaat werken dan doe je USB-stick er in en dan kan je daar je mail weer lezen.
[/quote]
Je kan dan gewoon de private RSA key van de USB stick af kopieren (een trojan zou dat bv ook kunnen doen zonder dat jij het merkt).
Die werken als volgt: de sleutel staat op het apparaat maar kan er niet af gekopieerd worden. Alle cryptografische operaties vinden op het apparaat plaats. Het token is beveiligd met een PIN code.
Omdat de drivers Windows Cryptography API (CAPI, niet te verwarren met de ISDN CAPI) ondersteunen, kan elke applicatie er gebruik van maken. Zo kan je bijvoorbeeld ook inloggen in een web applicatie die dit ondersteunt.
Kosten: zo’n 75 euro per stuk. Als je ze in het groot inkoopt kan je altijd een leuk prijsje maken.
Je kan dan gewoon de private RSA key van de USB stick af kopieren (een trojan zou dat bv ook kunnen doen zonder dat jij het merkt).
Ik denk dat jij gelijk hebt. Het is beter om zo’n USB stick te gebruiken waarbij je niet de geheime sleutel er af kan halen.
Deze stick gebruiken voor mijn persoonlijke spullen zoals emails.
De peer gaat ook verzoeken uitvoeren ook als jij er niet bent, dus denk ik aan 1 of meerdere keys te gebruiken naast zo’n magic usb-stick. Kan deze geheime keys wel in database zetten of op filesystem.
Vandaag beginnen om subscriber te vullen. In eerste instantie gewoon een lus maken door 1 record uit subscriber_white te lezen. Hierna velden achter elkaar plakken die voor de hash nodig zijn. Daarna de hash (=GUID) berekenen en de record met hash in subscriber gaan opslaan. Hierop het volgende record lezen.
Je krijgt dan een telefoonboek met hashcodes. De hashcode van je eigen peer in tabel ‘Config’ zetten bij GUID. Foonsearchd.exe zet dan de public key bij de subscriber entries die je eigen GUID hebben. Andere peers kunnen gemakkelijk je Public key lezen door een netwerkquery op je database uit te voeren.
Echter ik ga ook een PINGPEER en PONGPEER record structuur maken. Hierin komt naast public key ook hash van public key van de peer en GUID te staan. Met de GUID koppel je de peer aan het telefoonboek.
Subscriber tabel zie ik meer administratief. Met PINGPEER/PONGPEER kom je snel achter wie de andere peer is.
N.B. Met een PONGPEER krijg je ook je public ip adres terug van een andere peer. Momenteel stel je nog handmatig je public ip adres in en daar wil ik vanaf.
Uitdaging is om ook iets met subscriber pink te doen. Een soort merge tussen pink en white gaan maken. Daarnaast is een uitdaging om relevante velden uit info records gaan halen om die ook in hoofdrecord te zetten. Denk hierbij aan email adres, url, etc.
De subscriber tabel zie ik als onderdeel van het framework is bij mij foonsearch2006 database. Ik kijk momenteel ook weer naar de dikke van dalen. De dikke van dalen zie ik als een toepassing ‘op’ het framework. Ik denk aan om een databasebase woordenboek of in het engels dictorary te maken. Hierin tabellen maken die voor de dikke van dalen nodig zijn. Als je een woord opzoekt gaat een netwerkquery niet in foonsearch2006 zoeken, maar in dictorary.
Aanleiding: In het Noorden heb ik tweede netwerkkaart in pc gedaan. Echter tweede netwerkkaart krijg ik de default gateway niet zo dat ik met mijn laptop op internet kom. Ik kan pc aan internet wel bereiken via de tweede netwerkkaart. Je zou dus wel kunnen gaan browsen door http(s) verzoeken (=netwerkquery’s) te versturen naar foonsearchd op de pc die aan internet is gekoppeld. Deze gaat met wget naar de site toe en zet het resultaat in queryresult blobveld en stuurt queryresult berichtjes terug naar foonsearchd op mijn laptop.
Het is mij net gelukt om mijn rip van wget met foonsearchd mee te laten compileren.
Het principe is dat je een netqueryquery met bijvoorbeeld het volgende verzoek naar een willekeurige peer zou kunnen sturen.
Deze peer krijgt de netwerkquery en voert hem uit door met de “wget code” de informatie te gaan halen en slaat het resultaat in bijbehorende queryresult veld op. De peer verstuurt het resultaat in x queryresult berichtjes terug aan je peer. In dit geval is x = 1, want result is kleiner dan 65 kbyte. Je peer gaat de x berichtje(s) weer mergen in het queryresult blob veld van je peer. Een “programma” zal je moeten hebben om de velden uit het queryresult blob veld te kunnen interpreteren. Het programma zou in een inline programma kunnen zijn of een soort scripting of een KvK.DLL die je aankoppelt als het nodig is. Laatste oplossing heeft momenteel mijn voorkeur.
Op zich een mooi stuk over schaalbare servers gebruikmakende van IOCP. Zie ook http://www.codeproject.com/internet/IOCPScalableServer.asp Momenteel zit ik er zo in dat ik eerst iets aan de praat wil hebben en mogelijk kan je in later instantie wel een optimalisatieslag met IOCP techniek uitvoeren.
Ik heb een veld “configuration” in UDPMessage gemaakt, met:
bit 0: value 0: peer can be reached from internet (public ip), value 1: cannot be reached from internet (NAT).
bit 1: value 0: not behind firewall, value 1: behind firewall.
bit 2: value 0: not using a proxy peer, value 1: uses a proxy peer if you want to send a (network)message (*).
Je stuurt eerst een PING berichtje naar een andere peer met configuration = configuration & 0xFFF8. Krijg je een PONG terug dan weet je dat je via internet te bereiken bent. Krijg je niets terug dan stuur je een PING met configuration = configuration & 0xFFF9. Je zit dan mogelijk achter een firewall te werken. De ontvangende peer houdt dan de connection (socket) open. De andere peer stuurt dan via de nog openstaande (socket) verbinding berichtjes aan je op. Ik denk dat je kan checken of de verbinding nog werkt door op gezette tijden bijvoorbeeld elke 10 minuten een PING te sturen. De andere peer kan de verbinding sluiten als hij geruime tijd geen UDP packets aan je peer hoeft te sturen. Omdat je toch een database gebruikt zou je ook actief de packets kunnen gaan selecteren die voor jouw peer die achter fire wall zit te gaan versturen. Ik heb nog niet zo’n beeld of dit wel een goede zaak is. Eigenlijk zou je geen onderscheid moet maken bij de verwerking van packets welke voor peers zijn die wel of niet achter een firewall te bereiken zijn.
Ben je weggevallen dan opnieuw een UDP connection opzetten. Moet nog gaan testen of wat ik bedacht hebt werkt.
De vriendelijke groet Jan Marco
P.S. Ik ben erg blij met mijn nieuwe UDPMessage formaat. Best wel flexibel. Moet nog wel veel testen en zaken gaan programmeren dat het goed gaat werken.
(*) In de subscriber record aangeven welke publieke ip/dnsnaam je gebruikt als ‘proxy’. Het lijkt mij dat je de UDP resultspackets naar deze proxy gaat sturen. Je hoeft dan geen socket connection open te houden. Het openhouden van socket connect heeft het nadeel dat je resource van je pc gaat vasthouden. Het vasthouden van resource gaat op den duur tegen je werken.
Het gebruik van proxy zie ik als je pc niet de gehele dag op internet online staat. Staat computer uit dan stuurt iemand een email naar je proxy en als je pc weer aanzet dan haal je berichtjes (Mails, voicemails, ik heb je proberen te bellen maar je was er niet, etc) weer op. Mogelijk mengvorm. Staat je pc aan dan rechtstreeks anders proxy adres pakken.
Gisteren veel regels uit foonsearchd.c gegooid. Ik zit nu op 29869 source regels.
Vandaag een “updater” project gemaakt om subscriber_white records in te gaan lezen in subscriber. Ik ga daarbij de GUID van elke record berekenen. Eerst nog met mijn oude hash. Ik ga over een tijdje over om in mijn hash ripe160 te vervangen door sha512. Daarbij wil ik over van hexa-decimale (4 bits) notatie naar letters/cijfers. N.B. 5 bits worden omgezet naar 32 cijfer/letter volgorde.
Vanavond ga ik ook ntpd er in mee laten compileren. Ik ga dus vijf programmatjes “integreren” in de demon, namelijk ntpd, wget, zip, upzip en foonsearchd.
Je pc’s in het netwerk hebben m.i. allemaal 1 GUID, maar elke pc in je locale netwerk heeft wel een andere peerid. Met de GUID (onderdeel online telefoonboek) maak je je bekend aan andere peers op het internet.
Ben bezig met een updater programma. Ik heb de velden voor de hash in lowercase gezet en ik zie dat er een spatie voor lastname staat. Bijvoorbeeld. ’ alberts en coppens’ en ’ satoor de rootas-de jong, l f en o’, dus spaties voor en achter veld aftrimmen lijkt mij een goede zaak.
Ik ga een owner (=hash=guid van owner) veld inbrengen in subscriber. Ik zal de entries zetten eerst op de hash van:
de telefoongids bv
postbus 77863
1070ll amsterdam
Om de verschillen met de cdfoon er uit halen kan je gewoon selecteren op alle records die niet op bovenstaande telefoongidshash staan. Om het online telefoonboek te synchroniseren hoef je m.i. niet veel records over de lijn te halen als je alleen de eigen records overhaalt.
Het is mijn bedoeling dat eindgebruikers zelf hun informatie aanvullen en hierbij de ownerveld op hun eigen naam gaan zetten.
[quote=“alkema_jm”]Hoi RGJ,
Ik ga een owner (=hash=guid van owner) veld inbrengen in subscriber. Ik zal de entries zetten eerst op de hash van:
de telefoongids bv
postbus 77863
1070ll amsterdam
Om de verschillen met de cdfoon er uit halen kan je gewoon selecteren op alle records die niet op bovenstaande telefoongidshash staan. Om het online telefoonboek te synchroniseren hoef je m.i. niet veel records over de lijn te halen als je alleen de eigen records overhaalt.
Het is mijn bedoeling dat eindgebruikers zelf hun informatie aanvullen en hierbij de ownerveld op hun eigen naam gaan zetten.
[/quote]
Slim. Maar ik kan dus ook telefoongids records vervalsen door de eerstgenoemde hash (die kan ik immers zelf aanmaken) te gebruiken?