Foonsearch

Hoi RGJ,

Het voordeel van laagdrempelig nieuwe informatie toevoegen heeft het nadeel dat je fake records kan gaan opvoeren. Ik denk hierbij: Wat is onze nadeel als iemand fake records heeft opgevoerd? Analogie sommige forum users zijn m.i. ook fake, echter heb ik daar echt last van?

Ik zie voor mij dat straks in de GUI met de rechter muisknop een entry kan weggooien. Je kan het naast lokaal ook in alle andere telefoonboeken automatisch laten verwijderen. Je stuurt onderwater een netwerkquery naar alle telefoonboeken toe met delete verzoek.

Peer Y kan de hash (=GUID) van een andere peer bijvoorbeeld die van jou gaan gebruiken. Een GUID moet je een beetje als een “kenteken” van een auto zien. Iemand anders kan ook met jouw kenteken rond gaan rijden. Best handig als je geen snelheidsbekeuringen wilt krijgen.

Een andere Peer X kan gemakkelijk zien of de GUID wel bij de peer hoort. Ter verificatie kan Peer X een met jouw public key ge-encrypte test string naar de peer Y sturen die jouw GUID gebruikt. Hij moet het dan met jouw privat key deze string gaan decrypten en de plain text weer met de public key van Peer X gaan encrypten en het resultaat weer naar Peer X sturen. Als Peer Y de privat key niet van jouw heeft (gekregen) dan lijkt mij het heel moeilijk om voorgaande verificatie goed te doorstaan.

Wel een punt is wat jij “moet” gaan testen is of jouw public key nogwel bij jouw subscriber entry staat. Dit kan straks vrij gemakkelijk uitgevoerd worden. Je stuurt gewoon (wekelijks) een netwerkquery naar alle telefoonboeken met het verzoek om de public key terug te sturen. Je krijgt het resultaat van elke telefoonboek in een separate blob veld (queryresult). Hierna een programma er over heen halen die kijkt of het goed staat, zo niet dan stuur je een netwerkquery naar het specifieke telefoonboek heen om de public key te updaten. Je kan na een bepaalde periode (paar uur) weer een netwerkquery sturen om te zien of het aangepast is.

Je kan dus als end-user (belanghebbende) zelf je eigen entry goed gaan zetten. Mogelijk komen er in de toekomst peers die aangeven dat ze de moderator zijn van bepaalde delen van de informatie (“content”). Je kan dan als end-user zelf beslissen of je alleen van zo’n peer wijzigingen toestaat.

Analogie: Stel dat Norton/McAfee dezelfde programma zouden gebruiken. Alleen verzorgt Norton/McAfee de identificatie van nieuwe virussen. Je hoeft dan als end-user alleen maar een abonnement op Norton of McAfee af te sluiten en dan krijg je de updates op de kenmerken (“content”) van de virussen. In het framework zit het virusprogramma dat met de verkregen kenmerken aan de slag gaat.

De vriendelijke groet Jan Marco

Hoi RGJ,

Ik heb 1139945 white_subscriber getest en 1123319 unieke hashes gekregen, dus 16626 dubbelen zaten er nog in.

Ik denk momenteel ook om een vertaling van lastname te maken naar keywords.

bijvoorbeeld “1024 Webdesign & Vormgeving”, zou de volgende keywords kunnen opleveren ‘1024’, ‘Webdesign’ en ‘Vormgeving’.

We zouden ook de dikke van dalen kunnen gebruiken om keywords op te zoeken. ‘Webdesign’ staat er niet in, echter ‘Vormgeving’ wel. Je krijgt per entry een rijtje met keywords en de gewichten van de keywords. N.B. Adviesbureau zegt niet zo veel, want daar zijn er zo veel van.

Ik zie dat er drie lastname=‘11 Makelaars BV’ in de foondump voorkomen. Mogelijk een unity hashcode veld in subscriber gaan maken. Hierin een van de drie guids pakken en in deze unity veld gaan kopieren. Bij winkelketens zal je dezelfde naam ook met verschillende entries tegenkomen. Als je wilt corresponderen dan dit met guid van unity veld gaan doen, als je iets wilt halen van de “winkel” dan zoeken naar dichts bijzijnde filiaal. Je hebt hetzelfde bedrijf ook wel met verschillende lastname’s. Makkelijkst is om voor elk van deze namen een entry op te nemen en daarbij het unity veld gelijk aan elkaar maken.

De vriendelijke groet Jan Marco

Is er een koppeling tussen GUID en keypair dan?

Fietsenmaker A die de telefoonnummers van Fietsenmaker B tot en met Z op het zijne zet bijvoorbeeld. “Wij” hebben geen nadeel, maar die fietsenmakers wel. Achteraf controleren vind ik geen optie, het kwaad is al geschied. Wanneer het controlemoment bekend is, is dit overigens eenvoudig te bedriegen (even snel goedzetten)

Hoi RGJ,

Eerst even jouw eerste vraag beantwoorden:

Ja, De GUID is de hash van de subscriber entry. Lees telefoonrecord. Je wilt niet met rj jansen, stedum identificeren, maar met een hash code. De GUID kan je als een “kenteken van een auto” zien. Je kan in subscriber de overeenkomstige “RDW gegevens” (naam, adres, woonplaats, etc) opzoeken.

De public key wordt door foonsearchd.c op de pc (peer) aangemaakt. De hash (sha512) van deze public key is de indentificatie van de peer. De public key zal door foonsearchd.c in subscriber worden geladen overeenkomstige de GUID die je zegt te zijn.

In de nog te ontwikkelen peer tabel ga ik de peers bijhouden. Ik ga de gevonden peers actief om de GUID vragen en dan heb je de koppeling met subscriber (telefoonboek). De Peer tabel is gepositioneerd tussen Subscriber- en Send/Receive tabel.

Je hebt meerdere pc’s vaak in een netwerk staan, ieder pc heeft een eigen public key. Deze pc’s hebben allemaal dezelfde GUID.

Echter 1 (*) van de pc laat je met buitenwereld communiceren en daarvan laadt je public key in subscriber tabel. Voor de andere pc’s blijven de public key’s in de peer tabel steken. N.B Public keys hebben ook bepaalde houdbaarheidsdatum. Na bepaalde vervaldatum wordt er weer een nieuwe aangemaakt. Indien public key in het telefoonboek staat dan moet je netwerkquery uitzetten om hem te laten updaten.

De vriendelijke groet Jan Marco

(*) het kan zijn dat je meerdere pc met internet laat communiceren, echter dan maak je m.i. meerdere subscriber records aan. Denk hierbij aan verkoopafdeling, werkplaats, magazijn van de garage bedrijf. In subscriber (telefoonboek) heb je dan drie entries.

Ik lees hierin dat je dus voordat je een GUID “kaapt” ook even de key moet aanmaken, maar dat die evengoed te vervalsen is…?

Dat het om die hebzucht ging had je toch al kunnen weten, na alle posts in dit forum die verhalen over hoe de Telefoongids bv voor nog meer miljoenen in weer andere handen is gekomen :smiley:

Hoi RGJ,

Ben aan het inserten in subscriber.

Eerst pink gedaan. Ik heb 731336 records geprobeerd te inserten, 624621 zijn gelukt, dus 106715 “dubbelen” zaten in Pink. Dus 14,6 % van 731336 Pink records. Mogelijk krijg je deze dubbelen doordat een bedrijf in meerdere steden opgenomen wil worden in de cdfoon.

Hierna direct begonnen om white te gaan inserten. Een tussenstand is dat ik 2.381.745 white records heb geprobeerd te inserten, echter 2.191.030 gelukt, dus minstens 190715 “dubbelen” in white onder voorwaarde dat Pink al geinsert is.

De volgende tussenstand is 4.288.728 white en 3.965.807 geinsert, dus 322921 (= 7,5% van 4.288.728) “dubbelen”.

De eindstand is 5.627.195 white en 5.211.171 geinsert, dus 416024 (= 7,4% van 5.627.195) “dubbelen”.

Totaal (Pink + White) zitten er nu 5.835.793 records in subscriber. Ter illustratie Pink_subcriber heeft 731337 en White_subscriber 5627199, dus 1 - ( 5.835.793/(5627199+731337)) = 8,22 % dubbelen zitten er in als je naar de samenvoeging van Pink en White kijkt.

De vriendelijke groet Jan Marco

P.S. Het duurt 5 dagen om Subscriber te vullen. Ik selecteer momenteel maar 1 record. Zou wel meer records kunnen selecteren, echter optimalisatieslagen ga ik later mee aan de gang.

Hoi RGJ,

Gisteren Ripe160 vervangen door SHA512. Het is mij net gelukt om een routine te maken die de hexadecimale GUID outputstring omzet naar een 5 bits variant, namelijk uit de range “0123456789ABCDEFGHIJKLMNOPQRSTUV”. De GUID (hash van subscriber entry) is nu 143 karacters lang.

Welke zaken zet je in de GUID (hash van subscriber entry) is wel een vraagstuk voor mij. Als je het veld bankaccount in de hash op zou nemen verandert de hash direct als de enduser of iemand anders de bankaccount voor een subscriber entry gaat invullen. Als je een oude GUID hebt waarin backaccount nog niet gevuld is dan kan je de nieuwe GUID vinden door in de GuidUnity van oude entry naar de nieuwe laten verwijzen. Je kan ook iets met datums in subscriber record doen, dat een entry per bepaalde datum niet meer “geldig” is. Een andere mogelijkheid die je straks hebt is dat je alle online telefoonboeken (subscriber tabel) kan laten updaten. Je hebt ergens een oude Guid en je wilt graag weten wie dat nu is. Indien je de oude GUID uit de andere telefoonboeken laat poetsen kan je deze resolutie natuurlijk moeilijker uitvoeren.

Je maakt met postbank online geld aan iemand over en de bankaccount + beschrijving komt (“automatisch”) in subscriber te staan.

Gisteren ook naar de info records gekeken. Ik heb twee velden extra naast ‘mailbox’ opgenomen namelijk ‘PostalcodeMailbox’ en ‘CityMailbox’. Ik zag dat een bedrijf naast een bezoekadres ook een postadres met andere postalcode/city gebruikte.

Vandaag verder kijken naar de info records. Ik probeer zoveel mogelijk in 1 subscriber tabel te doen.

Om de entries te gaan linken met ‘GuidUnity’ veld kan je updateslag gaan maken via ‘phone’ veld. Als je “select from subscriber where phone = ‘0505445630’;” uitvoert krijg je alle funprice vestigingen. Je zou een GUID kunnen pakken en in GuidUnity kunnen kopieren. Mogelijk zou je ook via Kvk er achter kunnen komen welke de hoofdvestiging is. Ik kan mij nog herinneren dat hoofdvestiging weer een andere niet in foondump staande “entry” zou zijn. Mogelijk ga je via Kvk deze nieuwe entry in subscriber invoeren en de Guid van deze entry kopieer je naar de 5 vestigingen van Funprice.

De vriendelijke groet Jan Marco

Hoi RGJ,

Ben bezig om aan de hand van de postcode de overeenkomstige wgs84_lat en wgs84_lon in subscriber te copieren. Postcode GPS-coordinaten geeft een goede indicatie waar een subscriber-entry zich bevindt. Als je later je echte GPS-coordinaten weet dan deze gaan invullen. Als je deze GPS-coordinaten in subscriber hebt kan je m.i. gemakkelijk zoeken wie (personen + bedrijven) bij jou in de buurt wonen.

Als je alle entries wil hebben met een straal van 10 kilometer om je heen dan kan je eerst gemakkelijk een blok uit subscriber halen die net zogroot is als waar de denkbeeldige 10 kilometer cirkel inpast. Hierna de records gaan ophalen en dan pas de afstand berekenen of ze in de denkbeeldige cirkel vallen of niet.

Ik zie dat bij bepaalde postcodes geen records te vinden zijn in geo_postalcoords. Zie ook de appendix voor een aantal voorbeelden. Mogelijk dat er ergens op Internet een andere een bestand is waar we de missende wgs84_lat en wgs84_lon van bepaalde postcode kunnen verkrijgen.

De vriendelijke groet Jan Marco

Appendix A: enkele voorbeelden waarvan in geo_postalcoords tabel geen entries zijn:

postcode=1250AB is niet gevonden in geo_postalcoords!
postcode=1104AS is niet gevonden in geo_postalcoords!
postcode=3200AH is niet gevonden in geo_postalcoords!
postcode=7240AD is niet gevonden in geo_postalcoords!
postcode=9200AG is niet gevonden in geo_postalcoords!
postcode=2994LE is niet gevonden in geo_postalcoords!
postcode=5240AH is niet gevonden in geo_postalcoords!
postcode=3890AC is niet gevonden in geo_postalcoords!
postcode=3720AD is niet gevonden in geo_postalcoords!
postcode=9750AE is niet gevonden in geo_postalcoords!
postcode=1600AA is niet gevonden in geo_postalcoords!
postcode=3770AD is niet gevonden in geo_postalcoords!
postcode=1270BB is niet gevonden in geo_postalcoords!
postcode=8800AA is niet gevonden in geo_postalcoords!
postcode=1040LC is niet gevonden in geo_postalcoords!
postcode=3004GC is niet gevonden in geo_postalcoords!
postcode=1117ZP is niet gevonden in geo_postalcoords!
postcode=1070AB is niet gevonden in geo_postalcoords!
postcode=8330AC is niet gevonden in geo_postalcoords!
postcode=8903JN is niet gevonden in geo_postalcoords!
postcode=6600AL is niet gevonden in geo_postalcoords!
.
.

Dat zijn bijna allemaal voorbeelden van postcode’s die toegekend zijn aan postbussen

.

Postcode.nl is daar snel mee klaar:
http://www.postcode.nl/index.php?goto=shop&ItemID=32745][i]“Postcodes behorende bij postbussen (bijv. 1000AA) hebben geen coördinaten.”[/i

De gedachte is kennelijk dat je daarvan geen x en y kan bepalen, bijvoorbeeld de eerste postbus-postcode uit jouw lijstje, 1250AB, geeft als postcode 1251LE voor de meest waarschijnlijke vestiging, een postkantoor in Laren, als je in de locatiezoeker van postkantoor.nl
http://locatiezoeker.postkantoor.nl
op postcode 1251 zoekt. Klik je dan op “kaart” en ga je daarna bijvoorbeeld van ‘zoomniveau’ 2 naar 1 dan komen er ook coördinaten uit: xpos=143777 en ypos=474200.

Maar twee van je voorbeelden, 1104AS en 2994LE, zijn toegekend aan echte adressen, of liever gezegd 1104AS was toegekend aan Kikkenstein in Amsterdam-Zuidoost, de flat die in 1992 op 2 meter gemist werd door het neerstortende Israëlische vrachtvliegtuig. Die adressen zijn zo te zien na een renovatie (niet vanwege de ramp maar vanwege de herinrichting van de Bijlmer) vernummerd naar veel hogere huisnummers en in plaats van 1104AS hebben ze nu een postcode lopend van 1104SR tot 1104TR. Bij de laatstgenoemde hoort nu bijv. een huisnummerreeks 3334 t/m 3350, veel hoger dus dan de 375-393 resp. 374-392 voor die verdwenen postcode 1104AS.

Locatienet geeft gek genoeg nog wel coördinaten
http://tools.locatienet.com/finder/xml.1/xmladdress.asp?client_id=1002&password=demo&street=&postcode=1104AS&city=&country=NL
voor postcode 1104AS - die dus niet meer bestaat - en ook voor postcode 2994LE uit jouw lijstje:

[code]
451129_5186180_Deventerseweg_31 - 49_2994LE_BARENDRECHT__NL_
100
Deventerseweg
31 - 49
2994LE
BARENDRECHT
NL
451129
5186180

[/code] Los van de postbussen valt het wel mee met de ontbrekende postcode's in de 'Geo_postalcoords'-tabel. Maar omdat postcode's die in CD-foongidsvermeldingen voorkomen maar een "deelverzameling" zijn van de complete postcodetabel is er ook nog een lijstje te maken van postcode's voor adresreeksen waarvoor helemaal geen abonnee-vermeldingen bestaan en die van de CD-foongids-producent dan ook geen coördinaten meegekregen hebben. Op het totaal van 'Geo-postcoords', 443.000, zijn dat nog eens 4600-en-nog-wat postcode's (6-positie), bijvoorbeeld: [code]1332AR Almere 2583TH 's-Gravenhage 3311ZA Dordrecht 4531HM Terneuzen 5701HV Helmond 6041KS Roermond 7418AS Deventer 8924HR Leeuwarden 9742PW Groningen[/code]

Commerciële aanbieders:

    • Kadaster - Adrescoördinaten Nederland (ACN) http://www.tdn.nl/?inhoud=/zakelijk/producten/adrescoordinaten-nederland-en-geocoderen.html&navig=/zakelijk/nav_serverside.html%3Fscript%3D1
    • Postcode-nl - 4 positie XY-coördinaten database in een RD of Lat-Lon variant http://www.postcode.nl/index.php?goto=shop&ItemID=32745
    • Webservices.nl (nieuwe service van Postcode.nl) http://www.webservices.nl/index.php?PageID=37
    • Bridgis Adreslocaties® en Postcodelocaties http://www.bridgis.nl/index.php?subject=118
    • First Element - wederverkoper van adresdata http://element.nl/gis/index.html
    • Falk/Andes http://www.falk.nl/Producten/Geodata/Geodata/Centroïdenpolygonen.aspx
    • Cendris - Nationaal ReferentieBestand http://www.cendris.nl/cendris.nl/php/do_content.php?element_id=183
    • Tensing - wederverkoper van adresdata http://cms.tensing.com/LAS/APP=SEMPRO/_run/01,0181,000,00
    • AND - GeoAccess http://geoaccess.and.com/geoaccessinfo/default.aspx
    • lat- en lon-coördinaten http://www.geodan.nl/nl/producten/producten/4-positie-postcodedataset-van-nederland]Geodan
Alternatief:
    • [url=http://www.geonames.org]Geo-Names[/url]
Geeft coördinaten bij postcodes in een groot aantal landen, bijvoorbeeld [url=http://ws.geonames.org/postalCodeSearch?postalcode=1104&country=NL&maxRows=10[/url] voor de 4 eerste posities van bovengenoemde postcodereeks: 1104 **.

Hoi Weerman,

Erg bedankt voor jouw informatie —) Ik ga de ontbrekende GPS coordinaten van de postcodetabel aanvullen.

Ik ben momenteel op de helft (3 miljoen entries verwerkt):

Het aantal ontbrekende postcodes = 2329 in subscriber.
Het aantal ontbrekende GPS coordinaten = 7634 in subscriber.

De eindstanden zal ik rapporteren als het klaar is met inserten in subscriber.

De vriendelijke groet Jan Marco

Hoi Weerman,

De waterstanden van 24 uur later zijn.

3,6 miljoen subscriber entries verwerkt;
het aantal ontbrekende postcodes = 2506 in subscriber.
het aantal ontbrekende GPS coordinaten = 8120 in subscriber.

Misschien gaat het inserten niet zo snel meer, want ik ben maar 0,6 miljoen opgeschoten. wgs84lat en wgs84log velden heb ik een double veld in mysql gedeclareerd met een index erop. Mogelijk werkt double veld met index erop niet zogoed als een tekst veld. Kan ook wel aan iets anders liggen, moet ik nog beter uitzoeken waar het aan ligt.

De volgende query om een vierkantje op de kaart te selecteren “Select lastname from subscriber where wgs84lat > 52.220 and wgs84lat <= 52.24070418 and wgs84lon > 6.89261733 and wgs84lon <= 7.0;” levert 5458 records op en kost 25 minuten en 2.73 seconden. N.B. Ik ben wel ondertussen aan het inserten in subscriber. Mogelijk geeft dit nadelinge performance gevolgen. Ik wil natuurlijk snel de entries selecteren die in een ‘blokje’ op de kaart liggen. Ik moet nog beter gaan uitzoeken hoe dit te versnellen is. Mogelijk geeft een asci veld oplossing. Alleen zit je dan met de '." in het veld. Mogelijk (voor en na de ‘.’) aan gaan vullen met nullen. Principe waar ik aan denk is {wgs84lat > ‘000052.22000000’ and wgs84lat <= ‘000052.24070418’}

Mijn Guid is ‘2l6lgj9i3t3kk07hjeda3340neavpol2j0pqiaeiitr2l2ifnmjrgqpgo1pfpasig5q6vnfj1egqjo6u4uscf0pe5cns4gkq7hpdo8lmk6uivhr6o7ob8fk3vo6e018mvjvc3uc5t65krbo’.

De huidige peerhash is ‘1he6q0jba9r9o7gn9kd09d6nud3i9s8r0q1d8h2qr2o42fa5jieobb0918mevae70orqc2jgtp0rrh181jbjrrm9i2jc9h2a7k4dh09’.

Deze wordt initieel aangemaakt en verloopt ook over bepaalde tijdsperiode (automatisch). Als je nog berichtjes binnenkrijgt die versleuteld zijn met de oude peerhash dan stuur je deze peer gewoon een netwerkquery met een update van je nieuwe public key en peerhash.

Als ik een udp packetje (bijvoorbeeld een netwerk query) naar een andere peer stuur dan stuur ik deze peerhash mee. De andere peer ziet dat hij voor hem nog onbekende peerhash heeft binnengekregen. Hij stuurt dan een pingpeer packetjes aan mij, hierin zit ook o.a. zijn Guid en ik stuur dan een Pongpeer terug waarin mijn Guid inzit naast zijn public ipadres.

In subscriber ga ik nog een “anonymous” entry inserten. Deze Guid zet je default in foonsearchd.sql. De anonymous Guid geef je lage Importance, dus kan erg weinig zaken op je peer uitvoeren --)

De vriendelijke groet Jan Marco

Waarom ben je aan het denormaliseren en al die coordinaten in subscriber aan het opslaan?

(Zelfs!) met een join gaat het in ieder geval sneller:[code]
mysql> select lastname from white_subscriber s,geo_postalcoords p where p.postalcode=s.postalcode and wgs84_lat > 52.220 and wgs84_lat <= 52.24070418 and wgs84_lon > 6.89261733 and wgs84_lon <= 7.0;

8194 rows in set (1 min 13.49 sec)[/code]
Een double veld zou overigens sneller moeten werken dan een ASCII veld.

NB Mijn niet ‘aangevulde’ ZM1 database geeft bijna 3000 records meer dan jouw query?

Hoi RGJ,

Verklaring erg simpel. Ik ben namelijk nog aan het inserten. Ongeveer over de helft heen.

Erg goed punt. Ik wil de actuele coordinaten bij een adres hebben. In de nabije toekomst heeft iedereen wel een GPS (in de 06-telefoon zitten) en kan dan gemakkelijk gps-coordinaten invoeren. Indien ik de coordinaten als vast had gezien had ik hem in de Guid (Hashberekening) opgenomen.

Ik vul initiele waarde in m.b.t. Postcode-> GPS coordinaten resolutie. Mogelijk in de stad is een postcode gebied erg klein. Waar ik ben geboren was de afstand tot de dichtbijzijde buurman 600 meter. Deze lag aan de overkant van de weg. Buurman met dezelfde postcode zou best nog verder op hebben gelegen.

quote met een join gaat het in ieder geval sneller:Code:

Een double veld zou overigens sneller moeten werken dan een ASCII veld. [/quote]

Bedankt voor de tip: Als hij niet meer insert, kan ik beter even gaan testen op performance.

De vriendelijke groet Jan Marco

[quote=“Weerman”]De vorige CD-foonversie gaf vaak meer coördinaten voor een (6-positie) postcode, met als topper 1795 JX: 42 stuks x en y zonder enige spreiding voor De Cocksdorp, Texel.

Foondumpforum - Re: Coordinaten met versie 5.05?
http://www.foondump.nl/forum/viewtopic.php?p=1089#1089
[/quote]
In die posting werd ook een afstudeerscriptie aangehaald, daaruit:

[quote]De postcodes zijn op zodanige wijze aan adressen toegekend, dat elke postcode ongeveer even veel post ontvangt. Dit is gedaan door voor de invoering [van de postcode] te onderzoeken welke indeling gehanteerd werd bij de handmatige sortering in de postkantoren in het land. Het idee was dat de handmatige sorteerervaring had geleid tot een systeem waarin de vakken in de houten sorteerkasten optimaal benut werden. Tegenwoordig gaan achter elke postcode gemiddeld 16 postadressen schuil.

Genereren van een 6-positie postcodebestand op basis van de kadastrale registratie
http://www.gdmc.nl/publications/2003/Genereren_6ppc.pdf
[/quote]
Nog eens “gis_postalcoords” van een Java-foongids gehaald, coordinaten voor 1795 JX ontdubbeld en geplot in Excel, de onderlinge afstanden variëren van 7 tot 430 meter:

Het gaat aan dit centroïde
http://img333.imageshack.us/img333/3473/topokaartpy8.gif]kaartje
te zien - in dit geval afkomstig van de Nieuwe Kaart van Nederland (maar eigenlijk van Geodan) en waar onder andere ook een luchtfoto-laag aangezet kan worden - om een bungalowpark. De x en de y voor de twee 1795JX-coordinaten uit een recente “geo_postalcoords”, 119522 en 573871 zijn vast die van de [url=http://en.wikipedia.org/wiki/Centroid[/url] van dit plukje.

Hoi Weerman,

Altijd erg leuk te zien hoe goed jij de informatie boven water kan krijgen uit verschillende bronnen.

Gaat niet alleen om de onderlinge afstand maar ook om totale afstand. Je wilt een coordinaat hebben die precies aangeeft waar het is.

Ander punt is dat je ook een entry van het buitenland in subscriber kan opnemen. Ik zie het nut van geo_postalcoords+landveld. Als je een entry invult dan kan je default de GPS coordinaten uit geo_postalcoords gaan halen. Heb je de actuele GPS coordinaten dan deze gaan gebruiken.

Vandaag ook weer over een product tabel ( http://www.gepir.org ) nagedacht. Naast een SpotMarket tabel. Eerste tabel gelijksoortig aan Subscriber gaan maken. Je krijgt een hashcode om een product te identificeren. Deze laatste tabel linkt de product tabel aan de subscriber tabel. Denk simpel aan SpotMarket(Guid_subscriber, Guid_product, Prize, Currency, Sell/Buy, Number, Conditions).

De vriendelijke groet Jan Marco

Spotmarket (tabelnaam) lijkt mij wel een goede naamgeving voor de spullen die je in de winkel kan kopen.

Hoi RGJ,

Kwam er vanmorgen achter dat mijn hashstring niet goed is van mijn Guidberekening van de subscriber entries.
Vanmorgen met conversie programma’s van de SHA512 hash aan het prutsen geweest. Ik ga ook nog de hashberekening van de peer checken. Ga dan tevens kijken hoe ik de public key in mysql ga laden.
Het was voor mij handig om het te checken met andere SHA512 programma’s op internet. Je kan dan beter er vanuitgaan dat het goed is.
SHA512 hash berekening van gnunet was goed, alleen het omzetten naar asci kon ik niet volgen. Ik ben er wel achter gekomen dat je van “rechts naar links” moet werken.

  1. Hexadecimale (SHA512) hash van mijn voorbeeld testfile is:
    5aedd47c8cde93321115713bc14437834517061c04613478a5aa5db18151a6242982cb76eb27151f95aa3237de72e0f08b460a079b785df6736cd820a678cf6a

  2. Zelfde hash in “0123456789abcdefghijklmnopqrstuv” notatie:
    1derl3shjf96cgh2lojnga46u1ka5o63g262d3okml5rcc1a6j28ac2pdrem9ol3uaqkchnrppe1s4b8o50f6robnr76r6o42j7hjra

  3. Bovenstaande hash in HashCode512 formaat, de volgorde is van gnunet. De volgorde vond ik een beetje vreemd, maar gewoon gelijk gemaakt als bij gnunet, want ik heb ook procedure die HashCode512 omzet naar hexadecimalestring.

bits[ 0] = 7cd4ed5a
bits[ 1] = 3293de8c
bits[ 2] = 3b711511
bits[ 3] = 833744c1
bits[ 4] = 1c061745
bits[ 5] = 78346104
bits[ 6] = b15daaa5
bits[ 7] = 24a65181
bits[ 8] = 76cb8229
bits[ 9] = 1f1527eb
bits[10] = 3732aa95
bits[11] = f0e072de
bits[12] = 070a468b
bits[13] = f65d789b
bits[14] = 20d86c73
bits[15] = 6acf78a6

Je slaat in 2) formaat een peerid in database op. Als je een berichtje gaat versturen dan deze string omzetten in HashCode512 formaat (64 bytes).

De vriendelijke groet Jan Marco

Hoi RGJ,

Vandaag bezig geweest om foonsearchd.c weer aan de praat te krijgen, dus een netwerkquery op een andere peer gaan uitvoeren en het resultaat weer terug laten sturen.
Eigenlijk ga je alle stapjes checken en werkend maken.

Ter afwisseling wil ik nu ook met encryptie beginnen. Ik heb mij eigenlijk nooit zo met encryptie bezig gehouden, dus moet nog een beetje inleren hoe het werkt.

typedef struct
{
unsigned short len; // in big-endian, must be RSA_KEY_LEN+2
unsigned short sizen; // in big-endian!
unsigned char key[RSA_KEY_LEN];
unsigned short padding; // padding (must be 0)
} PublicKey;

PublicKey.len is bij mij 0x0601, je moet dit omdraaien, dus er staat 0x0106 = 256 + 2, 256 is RSA_KEY_LEN (2048 bits RSA public key, 2048 = 8 * 256).
PublicKey.sizen = 1, zal wel aanduiden dat byte de eenheid is.
PublicKey.padding = 0, wel vreemd is dat gnunet de Guid (hash) van de gehele PublicKey structure heeft genomen. Ik ga de Guid (hash) alleen van de 256 bytes Public key nemen. Ik vraag me af of je len, sizen en padding wel in database zou moeten opnemen. Je stopt toch gewoon de key in een blobveld en klaar is kees.

In http://www.codeproject.com/internet/YourOwnSecureProtocol.asp wordt de encryptie technieken een beetje uitgelegd. Ik ga nog naar wat meer codeproject projecten kijken hoe het werkt. Ik denk aan http://www.codeproject.com/internet/sslsocket.asp en http://www.codeproject.com/internet/casyncsslsocketlayer.asp

Ik denk dat ik de Helo berichtjes uit het protocol ga halen. Ik ga dit in PingPeer en PongPeer berichtje onderbrengen. Gnunet legt erg de nadruk op de Helo’s, zonder een Helo geen berichtjes. In mijn beeld als je een ip adres hebt en een portnummer dan kan je m.i. al met een peer gaan communiceren. Ik denk nog wel aan TimeStamp berichtjes. Hierna naar MQ (SAFMQ) kijken en dit proberen in te gaan bouwen. Met bepaalde berichtje maak je bij een (proxy) peer een queue aan en dan kan je bijvoorbeeld mailberichtjes er naar toe laten sturen. De queue maak je wel in MySQL aan, echter je krijgt berichtjes terug dat de queue wel of niet gecreerd is. Ik denk dat het optimaal is als je naast de flexibele netwerkqueries gestructueerde (MQ) commando’s gaat programmeren in het protocol.

De vriendelijke groet Jan Marco

Hoi RGJ,

Wel belangrijk is het aantal bits van de key. Zou kunnen zijn dat een paar bits van de laatste byte niet gebruikt wordt.

Ik copieer momenteel de public key naar een publickey tabel. Ook copieer ik de Public key + Hash van Public key in de Subscriber tabel. Ik moet de secret key tabel nog gaan vullen, dus eerst de secret key er proberen uit te halen.

Ik weet niet hoe het met een kabelrouter werkt. Als je een packetjes binnen krijgt zou 1 default pc deze ontvangen. Deze peer zou ook in Subscriber opgenomen kunnen worden. De andere pc´s die op hetzelfde ipadres (en dus dezelfde logische eenheid vormen = GUID) werken zouden alleen in de peer tabel moeten blijven steken.

Je kan natuurlijk ook meerdere ipadressen met hetzelfde guid laten configueren. M.i. zou dan de pc onderling moeten `laten´ onderhandelen wie de peer in Subscriber gaat worden.

Foonsearch zet alle binnenkomende udp packets direct in MySQL. Bij de verwerking ga je ook in Subscriber kijken wat de importance van de peer is. Zou ook best gelaagd kunnen worden. Als de peer in de peer tabel wordt opgenomen dat de importance uit Subscriber er bij copieren.

Volgende week ook de ‘mq’ veld in Subscriber vullen met het publieke ip:port, of dnsnaam:port. Denk ook aan een proxy veld te definieren, als je pc niet online is. Mogelijk deze proxy-informatie in een infoveld onderbrengen.

De vriendelijke groet Jan Marco

Hoi RGJ,

Het aantal ontbrekende postcodes = 2329 in Subscriber. (N.B. Ik moet ze nog ontdubbelen voor het precieze aantal).

Het aantal ontbrekende GPS coordinaten = 10737 in Subscriber.

Totaal staan er 5.835.794 entries in Subscriber. De verwerking heeft mij 8 dagen gekost.

Mijn huidige “performance” is 8643 rows in set (7 min 39.31 sec).

Het gaat nu zonder gelijktijdig inserten iets sneller (geen 25 minuten en 2.73 seconden), echter de snelheid is nog niet om naar huis te schrijven. N.B. Als ik bovenstaande query nog één keer uitvoer, dan duurt het maar 0.01 seconden. Ik weet niet hoe je deze optimalisatie uit kan zetten, want het vertekent natuurlijk wel het beeld. Mogelijk computer uit- en aanzetten of mysqld opnieuw opstarten om te voorkomen dat hij het berekende antwoord gaat pakken.

Bij mij zitten er nu wel meer records in 8643 – 8194 = 449 (Pink) records.

RGJ, Ik denk dat jij of XIM mogelijk wel een indicatie hebben waarom het zoeken in een GPS blokje bij mij niet snel genoeg werkt. Zou m.i. sneller moeten zijn als bij jou (1 min 13.49 sec). Zie onderstaande bijlage voor de details van mijn Subscriber tabel formaat.

De vriendelijke groet Jan Marco

Bijlage subscriber MySQL formaat:

[quote]create table subscriber ( #01
date varchar(8 ),
time varchar(9),
id bigint(16) unsigned not null,
importance bigint(15) not null default 0,#The current rating of this content
priority bigint(15) not null default 0,#How important is this request
guid varchar(256) default null,
GuidUnity varchar(256) default null,
title varchar(64) not null default’‘,#guid hash key
firstname varchar(128) not null default’‘,#quid hash key
infix varchar(64) not null default’‘,#quid hash key
lastname varchar(128) not null default’‘,#quid hash key
streetname varchar(64) not null default’‘,#quid hash key
housenumber varchar(32) not null default’‘,#quid hash key
postalcode varchar(16) not null default’‘,#quid hash key
city varchar(128) not null default’‘,#quid hash key
mailbox varchar(32) not null default’‘,#quid hash key
PostalcodeMailbox varchar(16) not null default’‘,#quid hash key
CityMailbox varchar(128) not null default’‘,#quid hash key
country varchar(128) not null default’‘,#quid hash key
state varchar(128) not null default’‘,
category char(16) not null default’‘,
email varchar(128) not null default’‘,
url varchar(128) not null default’‘,
sip varchar(128) not null default’‘,
mq varchar(128) not null default’‘,
wgs84Lat double not null default 0,
wgs84Lon double not null default 0,
wgs84Att double not null default 0,
PublicKey blob not null default’‘,
hash varchar(255) not null default’‘,
PkBits_len int(11) not null default 0,
PkExpirationDate varchar(8 ) not null default’‘,
PkExpirationTime varchar(9) not null default’‘,
phone varchar(32) not null default’‘,
BankAccountNumber varchar(64) not null default’‘,
BankAccountNumberDescription varchar(128) not null default’‘,
Bankname varchar(128) not null default’‘,
status varchar(255) not null default’‘,
action varchar(255) not null default’‘,
owner varchar(255) not null default’',
DateUpdateEntry varchar(8 ),
TimeUpdateEntry varchar(9),
DateBeginEntry varchar(8 ),
TimeBeginEntry varchar(9),
DateEndEntry varchar(8 ),
TimeEndEntry varchar(9),
index (importance),
index (priority),
index (title),
index (firstname),
index (infix),
index (lastname),
index (streetname),
index (housenumber),
index (postalcode),
index (city),
index (mailbox),
index (PostalcodeMailbox),
index (CityMailbox),
index (country),
index (state),
index (category),
index (email),
index (url),
index (sip),
index (mq),
index (wgs84Lat),
index (wgs84Lon),
index (wgs84Att),
index (PkBits_len),
index (PkExpirationDate, PkExpirationTime),
index (phone),
index (BankAccountNumber),
index (BankAccountNumberDescription),
index (Bankname),
index (status),
index (action),
index (owner(143)),
index (DateUpdateEntry, TimeUpdateEntry),
index (DateBeginEntry, TimeBeginEntry),
index (DateEndEntry, TimeEndEntry),
index (date, time),
key (id),
key (hash),
key (PublicKey(32)),
key (GuidUnity),
primary key guid (guid(143))
) type=myisam;[/quote]