Foonsearch

Hoi RGJ,

Gisteren weer een ingeving gekregen hoe ik ‘het beste’ kan gaan structureren. Ik ga gewoon een query tabel maken met o.a. de volgende velden:

query blob NOT NULL default ‘’,
queryresult blob NOT NULL default ‘’,

In query zet je de mysql query en het resultaat van de query zet je in queryresult blob veld. In een apart programma kan ik gemakkelijk blob techniek gaan testen.

M.i. zijn er twee mogelijkheden om een query/queryresult naar een andere peer te krijgen. Eerste methode is m.i. de gnunet techniek. Hak de queryresult in blokken en ga deze blokken naar de andere peer sturen. De andere techniek is m.i. het over te zenden als een ‘file’. Bijvoorbeeld met http://www.codeproject.com/internet/udt.asp . Je zet hierbij een UDP poort open op verzendende peer. De ontvangende peer gaat via UDP naar verzendende peer en haalt de file op. De UDP packets komen op deze manier niet in MySQL terecht. Stel dat een andere peer gelijktijdig ook iets op gaat halen op zelfde UDP port dan kom je m.i. snel weer in gnunet variant terecht. Hoe het precies gaat worden weet ik nog niet. Gewoon testen hoe verschillende andere projecten het hebben gedaan. Beste methode overnemen.

Denk om een aparte database te maken namelijk ‘foonsearch2006’. Ben bezig om de tabellen te updaten. Zie ook bijlage.

RGJ, In mijn gedachte ben ik nog opzoek naar wat de scope van foonsearch2006 zou moeten worden. Moet je filesystem en cd’s hashes er wel of niet onder laten vallen? Momenteel denk ik om alleen onderstaande tabellen er onder te laten vallen, dus de rest onder andere database namen laten vallen. CD hashen/opzoeken is dan een soort applicatie op/naast het framework.

De vriendelijke groet Jan Marco

Bijlage foonsearch2006 SQL contouren:

CREATE TABLE query(
.
.
query blob NOT NULL default ‘’,
queryresult blob NOT NULL default ‘’,
//hierin de queries opslaan en het resultaat van de query. Met gridcontrol (“excel achtige werkblad”) kan je m.i. makkelijk de query op scherm toveren. Als je op blob veld klikt dan een docking scherm open waarin je een nieuwe gridcontrol scherm opstart. Hierin kan je makkelijk de outputrecords tonen.

);
CREATE TABLE metaquery(
//alle queries uit query tabel halen en dan mogelijk meer queries in opslaan als je werkelijk hebt uitgevoerd, want die staan in de query tabel. N.B. Database Foondump2005 heeft bepaalde SQL structuur. Een soort geautoriseerde querys gaan maken. Je zorgt op deze wijze ervoor dat je dezelfde SQL structuur hebt en dat de SQL query’s die je dan ontvangt op deze database ook goed werken. Funprice en andere bedrijven definiëren hun structuur die je gemakkelijk zou moeten kunnen ophalen/verifiëren. De structuur die funprice gebruikt haal je dan bij hun server op.
);

CREATE TABLE receive(
//ik heb messagepack tabel gerenamed naar receive. In receive komen de messages packs binnen.
);

CREATE TABLE send(
De tegenhanger van receive is de send tabel. Hierin staan de messagepacks die verzonden moeten worden naar de andere peers. Gewoon een aparte tread maken die op prio/urgentie de messages packets gaat verzenden. De verstuur thread maakt de vertaling met welk protocol (UDP, TCP, etc) verzonden moet gaan worden.
);

CREATE TABLE queryblock(
//uit receive de queryblocks halen en in deze tabel zetten. Als je alle queryblokken hebt ontvangen dan kan je een query/queryresult in de query tabel gaan zetten.
);

CREATE TABLE ping(
//De receive verwerkingsthread zet alle pings in deze tabel.
);

CREATE TABLE pingIP(
//Met een aparte thread alle distinct ipnummers gaan checken of host ook te pingen is. Code voor zo’n ping procedure heb ik al.
);

CREATE TABLE pong(
// De receive verwerkingsthread zet alle pongs in deze tabel. Je stuurt eerst een ping naar een onbekende peer. Je krijgt in deze tabel een pong terug, hierop kan je een Helo naar de onbekende peer sturen om je bekend te maken. Je maakt met de Helo eigenlijk je eigen foondump entry bekend aan de onbekende peer.
);

CREATE TABLE helo(
//Hierin staan alle ontvangen helo berichten van andere peers. Een helo is een bericht om je bekend te maken aan andere peers. Door SQL te gebruiken kan je miljoenen Helo(s) opslaan. Eigenlijk is de Helo een foondump entry. Ik laat de Helo structuur nog even ongewijzigd want ik wil het huidige foonsearchd programma gaan testen in het gnunetd netwerk. Als ik ‘zenden van packets” ga aanzetten gaat het beter in het huidige gnunetd netwerk functioneren. Je kan dan gaan testen of het werkt zonder dat er veel functionaliteit in zit. Alleen Helo, Ping, Pong gaan werken in het gnunetd netwerk.
);

CREATE TABLE log (
//hierin alle log zetten.
);

CREATE TABLE config(
// de configuratie gegevens staan in deze tabel.
);

CREATE TABLE secretkey(
// de secret keys worden in deze tabel opgeslagen. Mogelijk in de toekomst in een andere database onderbrengen om betere beveiliging te realiseren. Mijn eerste doel is om encryptie te gaan testen. In later instantie meer naar beveilingsconcepten gaan kijken.
);

CREATE TABLE status (
// in deze tabel wordt het aantal ontvangen/verzonden bytes opgeslagen.
);

CREATE TABLE config_description(
// een beschrijving van een configuratie parameter wordt in de deze tabel gegeven. Als je een taal attribuut opneemt kan je gemakkelijk van taal omschakelen zonder de bron code te hoeven hercompileren.
);

Hoi RGJ, Poortprogrammeren is erg leuk om te doen --)

Het is mij net gelukt om een UDP-PONG uit te zenden naar de peer die de PING heeft gestuurd. Het werkt best wel mooi met MySQL.

Volgende week ga ik MySQL Query’s proberen te implementeren. Hierna tcp ‘gelijksoortig’ aan udp gaan maken. Daarna kan ik alle niet gebruikte source code er uit gaan verwijderen.

De vriendelijke groet Jan Marco

Hoi RGJ,

Om de tabbladjes in gridcontrol te maken kan m.i. met http://www.codeproject.com/tabctrl/AMCustomTabCtrlDemo.asp gedaan worden.

Vanmorgen met helo wezen prutsen. Werkt nog niet zo als ik het zou willen.

Ik ga straks beginnen om de query’s te gaan maken. Gewoon structuur van PINGPONG gebruiken en porten naar query en queryresult packets.

Ik stuur een query packet naar een andere peer. Indien de query maar uit 1 block bestaat dan bij aankomst andere peer direct in query tabel kopiëren anders de packets eerst in een tussen tabel (queryblock) zetten. Heeft de andere peer alle packets van query gekregen dan samenstellen en in query tabel kopiëren. Om het resultaat weer terug te krijgen maakt de andere peer een queryresult packet(s). Indien het resultaat uit meerdere packets bestaat dan gaat de peer die de vraag stelde hem weer samenstellen door packets uit tussen tabel te halen.

De vriendelijke groet Jan Marco

Hoi RGJ,

Ik ga rustig verder met boetseren.

De bedoeling is dat alle peers elkaar (automatisch) gaan vinden. Het uiteindelijk doel is dat een helo wordt gekoppeld aan een Foondump entry. Je kan je publiek Ipadres te weten komen als je een pong van een andere peer terugkrijgt. De andere peer ziet namelijk je publieke ipadres. Deze dan in de pongstructuur opnemen. Ik ga de komende tijd kijken om een beter helo,ping/pong te gaan maken. Gewoon naast de oude (gnunet) protocol positioneren. Omdat je in je database bijhoudt wanneer je voor het laatst een helo,ping,pong naar een peer hebt gestuurd, probeer je te voorkomen dat je veel netwerk verkeer gaat genereren. Vooral als je veel peers in je database hebt staan, moet je niet gelijktijdig query’s, pings,helo naar alle peers sturen. N.B. Met het Gnutella concept wordt het begrensd door TimeToLive (TTL). Ik ben meer voorstander om alle peers in je eigen database te hebben (“gedistribueerde Napster variant”).

Wat ik zie is dat ik met queue technieken (MQ) aan het bouwen ben. Een soort ‘fabriekje’. Integratie met SAFMQ kan m.i. op den duur geen kwaad.

‘Fabriekje’: Je krijgt UDP packets binnen, deze zet je in een MySQL queue. Een andere thread verwerkt deze packets. Is het een query packet dan wordt deze in de query tabel gezet. Zie ook onderstaande bijlage. Een andere thread gaat de query’s uitvoeren op de database. Laatst genoemde thread zet de resultaat-query-packets in de send tabel. Een send-thread stuurt de packets weer naar de peers, waarheen het resultaat gezonden moet worden.

De vriendelijke groet Jan Marco

Bijlage concept query tabel:

CREATE TABLE query(
date VARCHAR( 8 ),
time CHAR(9),
querySN BIGINT(15),
senderidentity_asci CHAR(33),
senderprotocol int(11) NOT NULL default 0,
senderip CHAR(20),
senderport CHAR(6),
isEncrypted CHAR(4), #YES if the message was encrypted, NO otherwise (LOOPBACK is a special value for messages that are to be treated as encrypted except that they are in plaintext)
priority BIGINT(15), #How important is this request (network byte order)
importance BIGINT(15), #The current rating of this content (in network byte order).
ttl BIGINT(15), #Time to live in cronMILLIS (network byte order)
QueryNumber BIGINT(15), #querySN of Query of requesting peer.

    query					blob   NOT NULL default '',
    queryresult				blob   NOT NULL default '',
   
    AddressTo				VARCHAR(255),
    AddressReturn			VARCHAR(255),
    QUID					VARCHAR(255),
    HashQuery				tinyblob	NOT NULL default'',
    HashQueryResult			tinyblob	NOT NULL default'',
    
    status                  VARCHAR(255),
    senderidentity          tinyblob     NOT NULL default '',
    INDEX(querySN),
    INDEX(senderidentity_asci(33)),
    INDEX(senderip(17)),
    INDEX(senderport(6))

);

Hoi RGJ,

Ik ga het resultaat van een query in een blob veld doen. Gewoon eerste getal in blob veld het aantal records laten zijn. Hiernaar recordnummer=0 er achter zetten, waarna kolomnummer en de lengte van headingveld1 er achter gezet kan worden. Waarna (variabele) headingveld1 er achter kopiëren, etc.

Even een voorbeeldje ter beeldvorming: Ik krijg vaak een albert heijn enquête formulier. Ik zet de vragen in een (mysql) tabel ‘enquête’ en vult de waarden via GUI in. www.ah.nl kan via query gelijksoortig aan “Appendix A” de waarden van de vragen in blob veld van mijn mysql server laten zetten en de blob veld automatisch (‘file’) naar de mysql server van www.ah.nl laten sturen. Als ik meerdere enquetes van verschillende bedrijven er in doe kan een andere peer een query maken om bijvoorbeeld alleen maar ‘klantvriendelijkheid’ er uit selecteren. Na verkrijgen query komt het in de blobveld te staan en wordt het resultaat naar de query aanvrager gestuurd.

De vriendelijke groet Jan Marco

Appendix A: query=’SELECT senderip, senderport FROM receive LIMIT 3;’

senderip|senderport|
127.0.0.1|3134|
127.0.0.1|3145|
127.0.0.1|3155|

Appendix B: QueryResult BLOB inhoud:

0003
0000 0:8:senderip 1:10:senderport
0001 0:9:127.0.0.1 1:4:3134
0002 0:9:127.0.0.1 1:4:3145
0003 0:9:127.0.0.1 1:4:3155

Hoi RGJ,

De komende week vrij genomen. Mijn intentie is om foonsearchd verder ‘af’ te ‘bouwen’.

Foonsearchd gebruikt myidenty key om een peer te identificeren en ik ga deze koppelen met een ‘foondump entry’. De afgelopen tijd best wel zitten nadenken hoe het zou moeten. Ik heb de nijging om het veel te breed te maken. Anderzijds moet het niet te smal worden dat je er niets aan hebt. Gisteren zat ik op de gedachte om alleen technische info om de peers te vinden en met de peers op internet te kunnen communiceren d.m.v. o.a. de query’s te maken.

Vandaag heb ik weer een andere ingeving gekregen om het probleem te solven.

Ik ga gewoon een “foononline” tabel maken in eerste instantie gelijk aan foondump white + 1 extra kolom, namelijk Globally Unique Identifier (GUID). Ik ga gewoon 100 entry’s uit white/pink halen om een voorbeeld tabel te maken voor het testen op de werking.

De GUID krijg je door de andere kolommen te hashen. De GUID wordt naar andere peers verzonden in de nog te maken PINGHELO en PONGHELO berichtjes. Pinghelo en Ponghelo werken naast de huidige ping/pong berichtjes. Ze krijgen alleen meer informatie. Denk hierbij dat je in PongHelo public ip adres terug kan sturen naar de peer die een PingHelo heeft gestuurd. Met Ping/Pong kan je snel zien of de andere peer er nog is.

Met de zwaardere PingHelo/PongHelo gebruik je meer om over te gaan naar andere myidenty key die bij een bepaalde GUID hoort. De (foonsearchd) myidentity key verandert in de loop van de tijd. Vaak wordt zo’n key met bepaalde levensduur gedefinieerd. Je gaat na verstrijken van bepaalde periode over op een andere (public/secret) keys. N.B. De GUID blijft ‘altijd’ het zelfde in de loop van de tijd.

Ik ga de komende dagen eerst om onderstaande (lowlevel) punten aan de gang. Hierna ga ik met de GUI programma verder. Je laat in het GUI programma gewoon de ‘foononline’-tabel op scherm zien m.b.v. gridcontrol en je gaat op een entry staan en kan dan met rechter muis “maak default fs peer o.i.d” aanklikken en dan zet je “gewoon” GUID van de geselecteerd record in foonsearchd. Je peer wordt dan bekend gemaakt aan de andere peers met de GUID die je hebt aangeven te zijn. Default zet ik een anonymous entry in de ‘foononline’ tabel, waarna foonsearchd.exe initieel naar laat wijzen.

Hierna ga ik kijken hoe ik de Wengo (Skype) variant hieraan kan koppelen. De code van Wengo heb ik al uit het Wengo project gehaald, echter moet alleen ‘aangezet’ worden in GUI programma.

De opgesomde puntjes waarna ik ga kijken.

  1. libeay32.dll en ssleay32.dll. Ik gebruik in foonsearchd nog een oude libeay32.dll. Ik ga het porten naar een ‘nieuwe’ versie die op hetzelfde niveau is als ik al bij wget gebruik. De load dll code van wget haalt ook meer procedures uit de dll’s. Daarnaast werkt https ook in wget, dus encryptie van de query’s kan ik afkijken van wget.

  2. Het maken van PingHelo/PongHelo.

  3. Public ip (DNS resolve) in PongHelo teruggeven aan zendende peer. In huidige gnunetd zie ik veel dat het public ip adres verkeerd staat doordat het administratief wordt gevuld. De fix die ik bedacht heb is dat als een public key een locale ipadres is, dan pak je het ipadres van het packet wat de ping/helo heeft verzonden. N.B. Het heeft geen zin om iets naar een locale ipadres te sturen als je weet dat de peer remote is.

  4. Punt waar ik nog mee zit is mag je naast een (gnunetd) senderidentity ook een GUID in de send tabel gebruiken. Je wilt soms een pakketje naar een GUID sturen. Echter ik denk dat het indirect moet. 1 GUID kan meerdere (gnunetd) senderidentity hebben. Je hebt dus een tabel (GUID, senderidentity). Echter wie maakt de vertaling:de (GUI) applicatie of foonsearchd.exe?

  5. Query’s uitvoeren uit query tabel. Indien myidentity van de query gelijk aan peer is dan query uitvoeren en het resultaat naar de query verzonden peer sturen. Indien het niet gelijk is dan query versturen naar senderidentity . Na verloop van tijd krijg je automatisch het resultaat terug in de query tabel (queryresult veld).

  6. Indien je query/queryresult, welke uit 1 blok bestaat, binnen krijgt in de receive tabel dan deze in query tabel kopiëren.

  7. Indien je query/queryresult, welke uit meerdere blokken bestaat, binnen krijgt in de receive tabel dan deze in queryblock tabel kopiëren.

8 ) Een verwerkingsthread maken die kijkt of alle queryblokken bij een bepaalde query binnen zijn. Indien dit zo is dan queryblokken naar de query tabel kopiëren en als dat goed is uitgevoerd de ‘gebruikte’ queryblokken uit de queryblock tabel verwijderen.

  1. Service programma code in foonsearchd.exe aankoppelen. Ook iets maken in commando regel om connectie met initiële database te bewerkstellingen. Denk aan (–u –p –d ) database opties.

  2. Threadpool programma code er in aanbrengen. Alle gebruikte threads in een structuur onderbrengen, zodat bij afsluiten van het programma alle threads goed worden gestopt.

  3. Mutex/thread code goed onder de loep nemen. Met Mutexen kan je aantal database connecties verminderen. Anderzijds moet je voorkomen dat je deadlock situaties krijgt. Een databaseconnectie kan je als 1 gebruiker van een database zien. Foonsearchd heeft meerdere databaseconnecties naar de database. Je kan het zien als dat er meerdere gebruikers in de database bezig zijn. Je legt het probleem zoveel mogelijk bij het databasepakket. Als je een selectie op database hebt gedaan kan je niet gelijktijdig met dezelfde database connectie een andere selectie doen. Als je bijvoorbeeld twee dasebase connecties hebt gemaakt kan je wel met de ene select alle records aflopen en gelijktijdig bij het aflopen andere database opzoek acties uitvoeren.

  4. Pingen van andere peers. De code heb ik al. Je hebt eigenlijk drie niveau’s, namelijk op ip-ping, (gnunetd) Ping en de nog te ontwikkelen PingHelo niveau. Welke strategie ga je gebruiken bij het checken of een andere peer nog aanwezig is of kijken of de andere peer nog wel de laatste helo van jou ontvangen heeft?

  5. Database back end er in programmeren. Je haalt de database code uit foonsearschd.c. Het voordeel is dat je dan gemakkelijker andere databases er aan kan koppelen. foonsearschd.c is dan generieke code. De specifieke database aanroepen staan in andere files.

  6. Log eerst in database en als dit niet wil dan in ‘syslog’ file.

  7. Naast UDP ook TCP gaan aanzetten.

  8. Public/Secret keys in database gaan zetten. Ze staan momenteel nog een file op het filesystem. Het liefst heb ik geen extra files op filesystem. Je ontkomt m.i. niet aan een syslog file als de database koppeling niet werkt. Alleen in uiterste nood log in de syslog file zetten.

  9. Schonen van de source code.

De vriendelijke groet Jan Marco

P.S. Sinds een paar dagen heb ik 1253 helo’s ontvangen, 13533 packetten in send verzonden naar andere peers. 13537 pings ontvangen. Bij elke ping wordt een pong in send tabel gezet. Het is m.i. gemakkelijk om in bestaand peernetwerk te ontwikkelen dan alles van scratch te gaan ontwikkelen.

Hoi RGJ,

Wat nu werkt is dat 1 peer (peer1) een query naar een andere peer (peer2) stuurt en deze stuurt het resultaat van de query (queryresult) naar peer3. Peer1 en Peer2 kunnen natuurlijk hetzelfde zijn. Krijg je m.i. een cliënt-server model met “fire and forget” principe.

Het ‘queryresult’ wordt geformatteerd in blobveld. N.B. De andere peer kan dan gemakkelijk het resultaat op het scherm toveren of de resultaatrecords verwerken in eigen database.

In query tabel staan de query’s. Elke query is uniek op een peer door de oplopende querySN veld. Als je een query naar een andere peer stuurt, krijgt hij een unieke querySN op ontvangende peer. Echter in het veld “QueryNumber” zet je de unieke querySN van vragende peer (query verzendende peer). Op deze wijze kan je m.i. makkelijk het antwoord aan de bijbehorende vraag koppelen in een gedistribueerde omgeving.

Ik ga dus eerst de “simpele techniek” maken: 1 vraag aan een specieke peer stellen, waarbij 1 antwoord terugkomt van de specifieke peer.

Later kijken hoe je 1 vraag, welke je aan meerdere peers gaat stellen, zou moeten programmeren. Denk bij deze 1:N relatie om dat in een aparte tabel onder te brengen namelijk ‘queries’.

De vriendelijke groet Jan Marco

Hoi RGJ,

Ik heb de Mysql structuur van foondump en foonsearchd gemerged voor een ‘onlinevariant’. Ik heb nu 21 mysql tabellen. De anonieme filesharing zaken heb ik uit foonsearchd.sql gehaald. Eigenlijk wil ik in het foonsearchd.exe programma alleen de bases programmeren.

N.B. Anonieme filesharing kan je in een ander programma er bovenop positioneren. Je maakt dan queries in messagepack formaat en zet deze in de send tabel (send queue) van foonsearchd.exe. Als de basis werkt kan je m.i. veel beter uitvogelen hoe je verder moet ontwikkelen. Anonieme filesharing/encryptie is naast een gebruikersvriendelijke GUI m.i. wel een belangrijk kritische succesfactor voor de toekomst --)

Daarnaast ben ik bezig om structuur uit
http://www.codeproject.com/internet/NetCnfgVersion2.asp te halen. Structuur zal ik in Mysql gaan zetten. Belangrijk is het locale ipadres. Public ipadres krijg je van een andere peer terug (ponghelo) als je straks een pinghelo gaat doen. Routering is dan mogelijk als je vanuit internet een pakket naar de ‘hoofdcomputer’ stuurt en deze routeert het naar de locale peer m.b.v. lokaal ipadres.

Ik heb een ‘ingeving’ gekregen hoe je het mergen van query/queryresult in queryblock kan doen. In het algemeen komt een Message packet binnen en wordt door een thread in mysql gezet in receive tabel. De verwerkingsthread (van receive) haalt messages uit de messagepacks en stopt bijvoorbeeld query/queryresult in queryblock, indien de query/queryresult uit meerdere blokken bestaat. Indien je een queryblock toevoegt dan houd je in de tabel querymerge bij hoeveel van de blokken je al binnen hebt gekregen. Indien je alle blokken binnen hebt dan status op “done” zetten en een nog te bouwen merge thread maken die dan alle query blokken samenstelt tot een query of een queryresult. Dit is afhankelijk van type block. De merge thread kan gewoon op status “done” laten zoeken.

Het verzenden van UDP packets werkt als volgt: Je haalt eerste packet op en maakt verbinding met de peer waar het packet heen gestuurd moet worden via een netwerk UDP-socket. Na het versturen close je direct de UDP-socket. Ik denk dat je de socket wel open zou kunnen laten staan en als je in de tijd gezien weer een packet moet versturen, doe je dat direct op een (nog) open netwerksocket. Echter ik denk dat je beter het volgende strategie kan doen: Je kan in mysql send tabel gaan sorteren op waar naar toe gezonden moet worden. Moet je meerdere packets versturen dan socket open laten staan totdat je een andere peer iets moet versturen.

Een ander punt waar ik tegen aan loop is dat prioriteit niet in het “gnunet UDP record packet” staat. Bij het ontvangen van een UDP packet kan je niet direct zien hoe belangrijk het packet is. In de messagepack kunnen queries staan die een hoge prioriteit hebben. Ik ga het UDP record niet direct veranderen, want dan werkt het niet meer in het Gnunet netwerk. Het voordeel om nog in het gnunet netwerk te zitten is dat je UDP-pakketten van andere peers krijgt en voor het testen is dat momenteel belangrijk.

Morgen ga ik verder om wat data in subscriber te zetten. RGJ, Ik hoop deze week iets kleins werkend te krijgen.

De vriendelijke groet Jan Marco

Hoi RGJ,

Even nagedacht op welke velden de guid betrekking zou moeten hebben. Ik denk momenteel aan guid = hash( title, firstname, infix, lastname, Streetname, housenumber, postalcode, city, country, state). Ik wilde telefoonnummer ook in de guid stoppen, echter door het bellen via internet straks een ander telefoonnummer of mogelijk straks helemaal geen tradioneel telefoonnummer meer beschikbaar?

Ik ga een thread maken die alle subscriber entries gaat aflopen en de guid hash gaat bepalen. De guid wordt weer in foonsearchd.exe gebruikt om je te identificeren aan de andere peers op het netwerk.

Een peer op het netwerk kan op mijn subscriber tabel een record:
a) toevoegen
b) deleten
c) updaten.

Opzich niets mis met bovenstaande operaties, echter als je niet zo eens bent met de uitgevoerde wijziging dan moet je het wel kunnen restoren.

Oplossingsrichting is dat je er een SQL interpeter tussen zet. Als je bijvoorbeeld een delete doet dan eerst “de te deleten records” saven in een bepaalde achive database o.i.d.

RGJ, Ik ga eerst het principe testen om records in (subscriber) in tevoegen, verwijderen of te updaten.

De vriendelijke groet Jan Marco

Appendix A: subscriber tabel:

create table subscriber ( #01
date varchar(8 ),
time varchar(9),
id bigint(16) unsigned not null,
guid varchar(256) default null,
title varchar(40) default null, #guid hash key
firstname varchar(128) default null, #quid hash key
infix varchar(40) default null, #quid hash key
lastname varchar(128) default null, #quid hash key
streetname varchar(64) default null, #quid hash key
housenumber varchar(24) default null, #quid hash key
postalcode varchar(9) default null, #quid hash key
city varchar(80) default null, #quid hash key
phone varchar(20) default null,
country varchar(128) default null, #quid hash key
state varchar(128) default null, #quid hash key
category char(5) default null,
email varchar(128) default null,
url varchar(128) default null,
sip varchar(128) default null,
mq varchar(128) default null,
wgs84Lat double
wgs84Lon double
wgs84Att double,
PublicKey blob NOT NULL default’’,
PkLen int(11) NOT NULL default 0,
PkExpDate varchar(8 ),
PkExpTime varchar(9),
status varchar(255)
);

Hoi RGJ,

Ik ben stevig bezig om de structuur van netwerkkaarten in mysql te zetten. De code haal ik uit:
http://www.codeproject.com/internet/NetCnfgVersion2.asp

Een netwerk tabel kan ik al vullen. Echter je moet er ook een andere tabel onderhangen waarin je ip, dsn en (gateway) per kaart in doet. Je kan bijvoorbeeld N stuks dsn-adressen definieren op een netwerkkaart.
Ik heb het ook omgezet naar simpele C code, want ik wil het in foonsearchd.exe gebruiken.

RGJ, Het heeft mij best wel wat tijd gekost om te begrijpen hoe het werkt.

De vriendelijke groet Jan Marco

Hoi RGJ,

Ik heb twee MySQL tabellen gemaakt, namelijk ‘network’ en ‘networkdetail’. Het enige waarop ik ben gestuit is dat de waarden van ip en subnetmask niet hetzelfde zijn als bij het configurationscherm als de kaart niet aangesloten is op een hub/switch. Blijkbaar wordt de informatie naar ander gebied gekopieerd als een netwerkkaart ‘goed’ functioneert. Deze ander gebied wordt door ‘mijn’ gebruikte routines uitgevraagd.

Gisteren ook geprobeerd of je vanuit internet ook bij je pc achter KNP (direct-asdl) aansluiting kan komen. Het is mij nog niet gelukt. Lijkt mij wel dringende reden om naar kabel internet over te gaan of andere adsl provider.

De vriendelijke groet Jan Marco

Hoi RGJ,

Opzet van foonsearchd heb ik anders dan Gnunetd geprobeerd te maken. Gnunetd (

) heeft een interne cron en zaken worden “random” aangeschopt. Je lost het dan op met mutexen en semaforen,etc, echter de kans is dan erg groot dat het op elkaar gaat wachten.

Christian geeft ook aan dat het moeilijk “fout zoeken” is. Zie bijlage A voor de details. Ik heb het meer als een basis gemaakt (het ontvangen, zenden en verwerken van berichten) waarin het afzonderlijk van elkaar blijft werken. De complexiteit kan je hierboven op programmeren. Je doet een messapack berichtje in de send queue en de send thread verstuurt het naar de peer die je hebt aangegeven.

Vandaag ga ik queryresult (block) berichtjes mergen tot een totaal queryresult in de query tabel. Het zal als een soort fabriekje gaan werken. Je krijgt queryresult berichtje in receive binnen en deze wordt, als het uit meerdere blokken bestaat in queryblock gestopt. Een andere thread gaat het straks proberen te mergen tot de oorspronkelijke output records.

De nieuwe gnunetd protocol gebruikt sha512 (104 asci karacters) ipv Ripe160 hash (32 asci karacters). Ik ben rustig begonnen om over te gaan naar de sha512 hash. Ik ga niet geforceerd over, want dan werkt het straks niet meer zonder dat ik weet waar het aan ligt.

Puntjes voor dit weekend:

  1. niet gebruikte code uit foonsearchd.c weggooien. Ik zit nu op 47834 regels en dat moet natuurlijk minder. N.B. Ik heb al een hele boel verwijderd --)

  2. Tabellen veranderen. B.v. ‘Peerid’ ipv. ‘senderidentity’.

  3. Splitsen van query/queryresults veld in query/queryresults-blokken om te verzenden naar een andere peer. Je stopt een blok in de send tabel en de send thread gaat het automatisch versturen.

  4. Samenvoegen van query/queryresults-blokken in de query tabel velden van query/queryresults.

  5. Onderzoeken of je ook blokken kan versturen die groter zijn dan UDP-MTU (1472 bytes) met send(). Ik denk dat send() VC het gaat opsplitsen in meerdere UDP packets, maar zeker weet ik dat nog niet.

  6. Foonsearchd werkt nog op oude protocol lees oude UDPMessage (bijlage B). Ik wil proberen om eerst naar nieuwe UDPMessage (bijlage C) over te gaan. Ik denk dat mijn UDPMessage (bijlage D) beter is, want je zet prioriteit/belangrijkheid in UDP message en dan kan je bij verwerken van packet rekening mee gaan houden. Je kan dit makkelijk implementeren door bij de mysql selectie de velden priority en importance te gebruiken. N.B de priority is afhankelijk van applicatie online, batch, etc. De importance wordt bepaald door de subscriber. Is het een anonieme peer of een bevriende peer? Je kan dan zonder in de UDP blok te kijken (te verwerken_de verwerkingsvolgorde veranderen. Vooral als je query/queryresults gaat encrypten is de verwerkingsvolgorde belangrijk, want encrypty/decrypty kost veel CPU power. Je wilt je bevriende peers sneller behandelen dan anonieme peers.

  7. Over gaan naar een nieuwe hash (sha512).

De vriendelijke groet Jan Marco

Appendix A: Info van Christian uit mail gehaald:

There are various operations (also gnunet-gtk shutdown, stop search, stop download) that take longer than I’d think necessary. The problem is, I’ve not yet been able to locate the problem.

Might be some thread sleeping (for say 50ms) and others waiting for it to respond, might be some very inefficient implementation of some part of the code, might be some issue with the TCP-IPC between gnunetd and clients.

Most likely it is even a combination of these – and the fact that multiple processes might be involved makes the diagnostics difficult.

I’ve not yet had enough time to figure it out, but it’s on my list.

Appendix B: De nieuwe Message-Packet header van Gnunet:
typedef struct
{
unsigned short size;// size of the message, in bytes, including this header.
short reserved; // Currently always 0.
PeerIdentity sender; // What is the identity of the sender (hash of public key)
} UDPMessage;

Appendix C: Oude Message-Packet header van Gnunet:
typedef struct
{
unsigned short size; * size of the message, in bytes, including this header;
unsigned short isEncrypted;// Is the message encrypted?
int checkSum;// CRC checksum of the plaintext (network byte order)
HostIdentity sender;// What is the identity of the sender (hash of public key)
} UDPMessage;

Appendix D: De nieuwe Message-Packet header van foonsearchd:
typedef struct
{
unsigned short size; * size of the message, in bytes, including this header;
unsigned short priority;// Is the message encrypted?
unsigned short importance;// Is the message encrypted?
int checkSum;// CRC checksum of the plaintext (network byte order)
PeerIdentity sender;// What is the identity of the sender (hash of public key)
} UDPMessage;

Hoi RGJ,

Vandaag heb ik het “proof of concept” van het “in mootjes gehakte” van queryresult gemaakt. Moet het nog beter testen op werking.

Het verschil tussen gnunetd en foonsearchd is dat foonsearchd zoveel mogelijk peers in de database wil hebben. Het liefst vele miljoenen peers. Bij gnunetd heb je maar een beperkt aantal hosts en die hosts sturen het door. Ik ga meer vanuit van een telefoonboek, waarbij je alle entries ook in je eigen database hebt.

Stel iemand wil de cdfoon naar iemand (X) anders sturen (Y) en wil het niet rechtstreeks doen dan zou hij de cdfoon in blokken kunnen hakken van 1024 bytes en naar 700.000 peers kunnen sturen met het returnadres van Y. Elke peer maakt maar een zeer klein gedeelte inbreuk op de rechten van de cdfoon.

RGJ, Bovenstaande is alleen maar een voorbeeld. Je begint met het uitwisselen van een paar (online) records. Het is ontzettend leuk om met peerprogramming en database programmeren bezig te zijn. Als de onderkant straks goed werkt dan ga ik direct verder om de GUI interface ‘af’ te gaan maken.

De vriendelijke groet Jan Marco

Hoi RGJ,

Even de huidige werking in hoofdlijn uitgelegd.

Op je eigen peer maak je een query aan, welke bestemd is voor andere peer. Je peer verstuurt de query naar deze peer. De remote peer voert de (MySQL) query uit en stuurt 1 tot N QueryResult packets terug naar je peer. De binnenkomende packets worden in queryblock opgeslagen. Een andere tabel (‘querymerge’) wordt bijgehouden hoeveel pakketten je al binnen hebt en als het aantal binnenkomende packets = het aantal pakketten (waaruit de QueryResult bestaat) wordt m.b.v. routine threadQueryBlockMergeMain() deze pakketten samengevoegd in tabel ‘query’ in veld ‘queryresult’.

Volgend weekend meer subscriber records aanmaken. Probeer met subscriber tabel te testen of het goed werkt.

De vriendelijke groet jan marco

Hoi RGJ,

Bij de cdfoon heb je een persoonlijk adresboek. Als ik naar mijn adresboek ‘vrienden’, ‘kennissen’ en ‘collega’s’ kijk verandert deze wel in de loop van de jaren. Ik denk momenteel aan “importance” en “prioriteit” veld in subsciber op te nemen. In mijn hoofd zit “urgentie” en “prioriteit” als velden. Moet dit nog een beetje naar Engelse termen transformeren.

Concreet geef je hogere importance aan in subcriber. Door selectie op importance kan dan gemakkelijk je “vrienden”, “kennissen” en “collega’s” uit subscriber halen en in een GUI tonen. Een site effect hiervan is dat deze personen voorrang op verwerking in foonsearchd.exe krijgen.

Een ander punt.

Als ik een record insert in subscriber ga ik eerst een select doen of de record er al in zit. Zo, nee, dan ga ik record inserten met id = max(id) + 1

Als je een insert doet vanuit een andere peer, dan krijg je m.i. problemen met tijdigheid. Je voert eerst selectie uit en stuurt resultaat terug (zit er wel of niet in en als niet in zit ook max(id)). Hierna gaat andere peer een insert sturen. Echter als er een kink in de kabel komt omdat je lager prioriteit hebt kan een andere peer een andere record inserten met de max(id) +1 die je berekend hebt.

Oplossingsrichting zou kunnen zijn dat je Local variabelen in de (MySQL) query in het query veld van de query tabel kan zetten. Voordat je de query uitvoert doe je een preprocessing en zet je locale variabele om in de echte waarden. N.B. Preprocessing van query’s die je van andere peers krijgt, kom je m.i. toch niet onderuit. Je wilt toch een risico check doen voordat je iets uitvoert.

De vriendelijke groet Jan Marco

Hoi RGJ,

Vandaag met de peer tabel aan de gang. De peer tabel is de verbinding tussen de administratief gevulde online subscriber tabel (telefoonboek entry) en de computer (peer) waarop foonsearchd.exe draait. Ook zullen er koppelingen met andere online database ontstaan. Bijvoorbeeld: Als ik geld over maak via mijnpostbank.nl zal ik de tenaamstelling van de rekeningnummer te weten komen van de persoon waaraan ik het geld overmaak. Deze info wordt in/aan subscriber gekopppeld. Als belangrijk is dan in het record structuur opnemen anders in de info tabel met verwijzing naar de subscriber id zetten. Ik opteer voor 1 online subscriber structuur voor personen en bedrijven.

De peer tabel wordt gevuld met de nog te ontwikkelen ‘pingpeer’ en ‘pingpong’ berichtjes. De oude ‘ping’ en ‘pong’ berichtjes kan je ook wel gebruiken, echter het zal m.i. niet de standaard instelling behoren te zijn. Anders geformuleerd: Alleen peers in de peer tabel kunnen records updaten en doen mee. Peers die niet bekend willen worden zullen niet veel prioriteit krijgen. Het kan wel zo zijn dat je iets (file, outputrecords, etc) van een ‘super’ onbekende wilt hebben en dan moet je dit nadrukkelijk gaan aangeven. Prioriteit neem ik al in de tabellen mee. Ik ga het eerst op een “first come first serve” manier testen. Je moet het niet direct heel complex maken. Eerst het aan de praat krijgen is nu voor mij van belang.

Ga nu beginnen om keyservice routine in een separaat programma te doen om het maken van een key en Helo te realiseren. Daarna keys opslaan in een database. Als het werkt dan de routines terug zetten in foonsearchd.c Momenteel sla je de keys nog op filesysteem op. Een optie in de tabel ‘config’ zal aangeven of je de keys op filesysteem of database opslaat. Default zal database worden. N.B. Je wilt eigenlijk geen files op filesysteem laten groeien. Alleen als de database niet werkt om de log info te ‘storen’ dan wel een syslog file op filesysteem aanmaken.

De vriendelijke groet Jan Marco

Hoi RGJ,

Ben met een separate programma bezig. Ik ga direct ook encryptie en decryptie meenemen. Ik wil ook zip- en unzipcode er in doen. Ik wil op totaal gaan zippen, dus niet op de afzonderlijke pakketten.

Je hebt bijvoorbeeld een file in blokveld queryresult staan. Eerst ga je het zippen en daarna de file in blokken hakken en afzonderlijk gaan encrypten met public key van de peer waar je het heen gaat sturen.

Gnunetd gebruikt EVP_bf_cfb (blowfish) om de helo te maken. De dll (libeay32.dll) die bij wget werkt geeft bij het laden van de EVP_bf_cfb() routine 0 terug. De libeay32.dll die ik bij foonsearchd.c gebruik geeft EVP_bf_cfb() wel een goede waarde terug, echter ik wil graag 1 libeay32.dll gebruiken die tevens bij wget werkt. In de toekomst ga ik foonsearchd met wget samenvoegen.

Ik denk om toch over te gaan naar de https encrypty, zoals ik dat uit wget kan gaan halen. Gnunetd zal wel voor blowfish hebben gekozen omdat het sneller zal werken dan RSA.

De vriendelijke groet Jan Marco

Hoi RGJ,

Even weer zitten zoeken naar ‘zippen’ en ‘encryptie’ op codeproject.

M.i. is http://www.codeproject.com/file/zip_utils.asp wel handig om het zippen/unzippen van files/queryresult te gaan doen.

Een andere programma op een DLL gebaseerd zipprogramma is http://www.codeproject.com/useritems/LiteZip.asp Lijkt veel op bovengenoemde, echter minder bruikbaar, wat zit in DLL.

De programmeur (dan.g) van todolist heeft op een ander project voorborduurt. Zie ook Win32 Wrapper classes for Gilles Volant's Zip/Unzip API - CodeProject Hierin zie ik generieke routines als schijf capaciteit, GetLastModified(), etc. N.B. De generieke routines zitten ook in todolist.

Zit te denken om de openssl dll te gebruiken bij (https) encryptie. Ik kan mij nog herinneren dat de openssl library ook in assembler is geprogrammeerd om snelheid te krijgen.

Om meer gevoel bij encryptie te krijgen ga ik toch (codeproject) projecten proberen en daarbij proberen om nuttige source code bij elkaar te ‘sprokkelen’.

Even een lijstje met projecten waarna ik gekeken heb:

http://www.eskimo.com/~weidai/cryptlib.html
Hash en encryptie routines.

http://www.codeproject.com/cpp/filecryptapp.asp
Om files te encrypten met Rijndael, Blowfish:

http://www.codeproject.com/file/fileenc.asp
File Encryption Utility based on Blowfish Encryption Algorithm.

http://www.codeproject.com/bitmap/ImgCrypt.asp :A simple and fast image encryption technique, which facilitates the secure use of external image files in common applications.

An Introduction To Web Service Security - Part II - CodeProject : M.i. geeft wel heel globaal aan met problemen wat je op moet lossen.

http://www.codeproject.com/cpp/encryption_selection_process.asp
Laat zien hoeveel de encryptie methode kosten aan cpu power. N.B. Schedule kolom begrijp ik niet.

http://www.codeproject.com/bitmap/ImgCrypt.asp : Is gemaakt om bmp files te encrypten. N.b. Krijg er nog geen files in de applicatie.

RGJ, Ik denk aan om twee extra veld in query tabel op te nemen namelijk queryzip en queryresultzip. Stel de image van een cd staat in query blobveld. Hierna deze blobveld gaan zippen in queryzip. Als je deze cd naar andere peer wilt sturen dan zipfile in blokken hakken en elke blok gaan encrypten voordat je het in een queryresult berichtje gaat stoppen. Het queryresult berichtje zet je in de send tabel. Het programma foonsearchd.exe zou dan de rest automatisch moeten doen, namelijk het versturen en mergen op de ontvangende peer. Het decrypten ga je op ontvangende peer alleen bij het mergen doen indien je alle pakketten hebt binnengekregen. Dus als het niet lukt om alles binnen te krijgen verspil je geen cpu cycles met decryptie.
Omdat je twee velden hebt de ene met plain query en de andere met gezipte query. Je kan er voor kiezen om status “archive” te gaan maken en dan de plain query weggooien. Als je plain query nodig hebt dan unzip je het toch gewoon weer.

De vriendelijke groet Jan Marco

Hoi RGJ,

Ik heb een test programma gemaakt om packets aan foonsearchd aan te bieden. Het maakt rechtstreeks de UDP packets aan en stuur het naar de locale udp port. Werkt best wel goed. Ik zal wel udp packets kwijtraken, want dat mag bij het udp protocol. Ik zal iets gaan maken dat je de missing packets nummers gaat terugsturen. Op verzendende peer zou je de “missing packets” in send tabel de status terug kunnen gaan zetten van “proccessed” naar “not processed”.

Heb nu ook encryptie routines in separate programma gedaan. Encryptie bevat ruwweg 20% van foonsearchd, namelijk 11000 van de 50000 source regels.

De files zip.cpp en unzip.cpp heb ik ook mee gecompileerd. De central directory heeft wel mijn aandacht. Zelf heb ik ook een formaat bedacht om MySQL output records te formatteren. Eigenlijk wil je iets maken dat ook met de zipvariant te lezen is.

Ik ga eerst met Appendix A variant prutsen. Kan ik een binary in blobveld laden. Hierna mijn file zippen in andere filename en hierna ook proberen in te laden.

Moet nog nadenken hoe je zippen van grote files in een blobveld doet. Mogelijk eerst naar filesysteem “downloaden” en hierna inladen in zip blobveld. Misschien kan het wel op een mooiere manier.

De vriendelijke groet Jan Marco

Appendix a: Load van blobveld vanuit een file:

C: aanmaken van zipfile:
hz = CreateZip(_T(“c:\var\bin\image.zip”),0);

ZipAdd(hz,_T(“znimage.bmp”), _T(“c:\var\bin\image.zip”));

CloseZip(hz);

SQL: inladen van files in blobveld:
create table image1 (
image longblob not null,
imagezip longblob not null
);

insert into image1 values (load_file(“c:/var/bin/image.bmp”), load_file(“c:/var/bin/image.zip”));

Hoi RGJ,

Ik heb de afgelopen dagen UDP pakketjes aangeboden aan foonsearchd. 555 Mb aan pakketjes zijn in de receive tabel opgeslagen. Ik zie nu dat mijn E: schrijf is volgelopen door de logging info van foonsearchd. Ik heb de loggingsfiles al weggegooid. Alleen is de vrije ruimte nog niet terug. Momenteel filesystemd programma over E disk heen halen en met “select filename, filesize from from order by filesize;” gaan zoeken waar de grote (verborgen) files zitten.

Afgelopen weekend een fout gevonden met het mergen. Ik stuurde met mijn test programma packketjes naar mijn adsl peer. Echter ik kreeg, nadat hij probeerde te mergen een (send to Microsoft) foutmelding.

Ga vandaag beginnen aan een resend tabel. In tabel querymerge houd ik al bij hoeveel pakketen zijn binnengekomen. Dus ook bij gaan houden wanneer je de laatste pakket hebt binnen gekregen. Na 3 minuten een resend pakket sturen. Ik wilde eerst iets complex maken. Een veld met alle queryblock nummers die je nog mist gaan zetten. Momenteel denk ik over een resend berichtje per queryblock die je mist. Ik moet eerst meer gevoel krijgen hoeveel UDP pakketjes je kwijtraakt.

De vriendelijke groet Jan Marco