Foonsearch

[alkema_jm]

Hoi RGJ,

Ben al weer een klein stukje verder.

Ik zie dat thread listenAndDistribute__UDP de packets in een queue zet. The threadMain thread verwerkt de packets weer.

Queues technieken zijn dus belangrijk. Je hebt natuurlijk ook met formule van little te maken. Je hebt gemiddeld meer verwerkingscapaciteit nodig dan er wordt aangeboden. Anders loopt de wachtrij op. Bij een bepaalde te verwerken packet stokt het voor langere tijd.

Ik denk dat ik de packets in MySQL ga stoppen in thread listenAndDistribute__UDP en verwerken in threadMain.

Ik heb ook iptraf geïnstalleerd op mijn Linux server om meer omgevingsinformatie te hebben,

De vriendelijke groet Jan Marco

[alkema_jm]

Hoi RGJ,

De werking is als volgt. Meerdere threads (UDP, TCP, SMTP, TCP6, etc.) voor elk protocol 1 halen packets (Helo, Ping, Pong, straks een SQL query) binnen en sturen deze door naar een buffer (queue). De mainthread verwerkt deze in de buffer staande packets.

De queue wil ik in MySQL gaan maken. Het grote voordeel is dat je de verwerking nog een keer over kan doen voor testdoeleinden.

De protocol threads kan je iets inbouwen of je de pakketen wel wil hebben. Ligt dicht tegen iptables aan. Je kan natuurlijk aangeven wat de prioriteit en urgentie van de packets zijn.

De verwerkende thread(s) kan batch gewijs sommige packets gaan verwerken. Denk hierbij aan metofoor “wasmachine”. Je sorteert wit en bont uit en gaan elk batch afzonderlijk verwerken. Dus niet 1 sok wassen en drogen en dan de volgende sok pakken. De verwerkende thread heeft veel met workload manager te maken.

Mogelijk online packets eerder verwerken.

Een mailtje is ook gewoon een bericht naast een helo. De versturende peer heeft het met jouw public key ge-encrypt. Mailtje gewoon in een blob in mysql opslaan.

Ik weet nog niet of SOAP protocol goed werkt met boven voorgestelde splitsing. Mijn manier van werken is gewoon doen en dan kijken of het beter kan,

De vriendelijke groet Jan Marco

P.S. Gnunet gebruikt erg gebaseerd op vaste packet grootte. Ik dacht dat bij TCP-IP geen vaste packet grootte heeft. Ik hoor wel vaak iets met MTU. Ik probeer het eerst aan de praat te krijgen en later te kijken of het efficienter kan.

[alkema_jm]

Hoi RGJ,

Ik heb even een message ‘aangevuld’ namelijk p2p_PROTO_SQL. Dit berichtje executeer je op je database.

Als je een email verstuurt doe je eigenlijk een insert (time, etc) into email database met bericht van het type p2p_PROTO_SQL. Bijlagen bij de email doe je in SQL met insert () into email_attachment database. Ik zie dat in 1 packet meerdere berichten gedaan kunnen worden.

Als Funprice de HP IPAQ H2210 in de aanbieding doet (voor bijvoorbeeld 300 euro) dat krijg je een p2p_PROTO_SQL binnen (van Funprice) met een SQL update prize=300 where () commando op de “product database”.

N.B. p2p_PROTO_TIMESTAMP zou iets met NTP moeten doen. Sommige peers zijn in sync met een NTP server (atoomklok). In de helo zou je bekend kunnen maken dat je een time gesynchroniseerde peer bent. Ik geloof dat er verschillende niveau’s van tijd synchronisatie zijn.

De vriendelijke groet Jan Marco

Appendix A: foonsearch berichten:
/**

• announcement of public key
  /
  #define p2p_PROTO_HELO 0
  /*
• session key exchange, session key is encrypted with hostkey
  /
  #define p2p_PROTO_SKEY 1
  /*
• PING
  /
  #define p2p_PROTO_PING 2
  /*
• PONG (response to PING)
  /
  #define p2p_PROTO_PONG 3
  /*
• timestamp (until when is the packet valid)
  /
  #define p2p_PROTO_TIMESTAMP 4
  /*
• sequence number (discard packet if sequence number
• is not higher than previously received number)
  /
  #define p2p_PROTO_SEQUENCE 5
  /*
• noise, used to fill packets to sizes >1k.
  /
  #define p2p_PROTO_NOISE 6
  /*
• termination of connection (other host is nice
• and tells us, there is NO requirement to do so!)
  /
  #define p2p_PROTO_HANGUP 7
  /*
• Advertise capability (or limitation).
  /
  #define p2p_PROTO_CAPABILITY 8
  /*
• Execute SQL statement
  */
  #define p2p_PROTO_SQL 9

[alkema_jm]

Hoi RGJ,

De fout die ik net gemaakt heb (met het overdragen van argumenten aan een thread) staat in http://www.llnl.gov/computing/tutorials/workshops/workshop/pthreads/MAIN.html uitgelegd.

De vriendelijke groet Jan Marco

[alkema_jm]

Hoi RGJ,

Status: Momenteel krijg ik wel packets binnen via het UDP protocol. De verwerking gaat ergens stuk. Ik zie dat hij de packets niet verwerkt en de CPU heeft 99,9 % utilization. Het niet verwerken en hoge CPU utilization zal wel een relatie met elkaar hebben.

Ik ga nu een message (een message kan een helo, ping, pong, sql-query, etc. zijn) database maken. Hierin worden de binnenkomende packets gestopt.

Bij de verwerking ga ik deze packets weer lezen uit de message database. Door gebruik te maken van een database wordt het wel transparanter hoe het werkt.

Ik zie dat de message ook een CRC heeft en dat het soms ge-decrypt moet worden bij de verwerking. Het is altijd wel een keuze in hoeverre je de verwerking bij binnen komen van een packet gaat doen. Ik blijf dicht bij de opbouw van het programma. Als het werkt kunnen we het altijd nog wel veranderen.

In de nog te ontwikkelen Visual studio (MFC) GUI zou je de messages database gewoon moeten kunnen zien.

De vriendelijke groet Jan Marco

P.S. Best leuk om een voorbeeld programma als Gnunet te gebruiken. Ik geef wel een andere invulling aan het programma. Best wel veel dingen die door Christian goed zijn bedacht.

Zelf ben ik bijvoorbeeld niet zo’n “call back methode” programmeur. In gnunet is “call back methode” best wel functioneel er in geprogrammeerd.

[alkema_jm]

Hoi RGJ,

Ik heb een messagepack tabel gemaakt. Ik heb wel ip + poortnummer uit UDP routine gehaald, want ik wil wel graag weten met welk adres men een packet stuurt. Ik ga er niet vanuit dat ipadres hetzelfde zou zijn als welke in de helo staat aangeven,

De vriendelijke groet Jan Marco

Appendix A: messagepack tabel:
mysql> select date,time,senderidentity_asci,protocol,senderip,senderport,messagepack_size,crc from messagepack;
±---------±---------±---------------------------------±---------±----------------±-----------±-----------------±-----------+
| date | time | senderidentity_asci | protocol | senderip | senderport | messagepack_size | crc |
±---------±---------±---------------------------------±---------±----------------±-----------±-----------------±-----------+
| 20041220 | 19:25:57 | SSLP6U23TL71SMNE2HHTKA489VFH4F8T | 17 | 84.131.153.207 | 2086 | 1084 | 402486571 |
| 20041220 | 19:25:59 | V0N2PUGNMU61KPPU0H606H3T011Q1600 | 17 | 128.10.19.51 | 2086 | 1084 | 3738254986 |
| 20041220 | 19:26:04 | 2STRBV567KFU5LE0IK962KR0RG0HSRB1 | 17 | 212.194.170.164 | 2086 | 1084 | 1155222801 |
| 20041220 | 19:26:10 | V0N2PUGNMU61KPPU0H606H3T011Q1600 | 17 | 128.10.19.51 | 2086 | 1084 | 1651025340 |
| 20041220 | 19:26:16 | 2STRBV567KFU5LE0IK962KR0RG0HSRB1 | 17 | 212.194.170.164 | 2086 | 1084 | 3778399190 |
| 20041220 | 19:26:16 | V0N2PUGNMU61KPPU0H606H3T011Q1600 | 17 | 128.10.19.51 | 2086 | 1084 | 313263848 |
| 20041220 | 19:26:19 | B02G5722N6HLQPU73NC7SNHKJ2ABQS8U | 17 | 24.27.170.193 | 2086 | 1084 | 3901043277 |

[alkema_jm]

Hoi RGJ,

De hele dag wezen prutsen. Ik heb de splitsing aangebracht tussen het verkrijgen van de packets en de verwerking. Er zit nog wel een fout in de verwerking. Ben momenteel bezig om deze uit te zoeken.

Je zou een week kunnen verzamelen en dan “de schuif open zetten” om het te laten verwerken. Of je laat de helo wel verwerken en de query berichten bijvoorbeeld niet.

Verbeteringen krijg je door het gewoon te doen. Vanmorgen kwam ik er achter dat ik weer een “out of sync error” had. In het kritisch gebied van een database select query ging ik naar de verwerkingsprocedure springen. Mijn huidige oplossing om de werkingsprocedure een andere databaseconnectie te geven.

Denk om een gewone logfile te gebruiken bij de database fouten. “Out of sync errors” lopen wel door maar “blazen” het programma m.i. wel op.

De vriendelijke groet Jan Marco

P.S. Out of sync error is een fout in de volgordelijkheid van de sql queries. Bijvoorbeeld je doet al een nieuwe query zonder het oude resultaat te releasen.

[alkema_jm]

Op deze manier kan je een Linux programma in debugger mode laten lopen:

gdb ./foonsearchd

run -d -L DEBUG

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1086680128 (LWP 4447)]
0x4207414b in _int_malloc () from /lib/tls/libc.so.6
(gdb) info threads
6 Thread 1103899328 (LWP 4451) 0xffffe002 in ?? ()
5 Thread 1103637312 (LWP 4450) 0xffffe002 in ?? ()
4 Thread 1095248832 (LWP 4449) 0xffffe002 in ?? ()

• 3 Thread 1086680128 (LWP 4447) 0x4207414b in _int_malloc () from /lib/tls/libc.so.6
  2 Thread 1078291648 (LWP 4446) 0xffffe002 in ?? ()
  1 Thread 1076126336 (LWP 4433) 0xffffe002 in ?? ()
  (gdb) ba
  #0 0x4207414b in _int_malloc () from /lib/tls/libc.so.6
  #1 0x4207335b in malloc () from /lib/tls/libc.so.6
  #2 0x40038f5a in my_malloc () from /usr/local/fsh/var/mysql/lib/mysql/libmysqlclient.so.12
  #3 0x400367b3 in mysql_use_result () from /usr/local/fsh/var/mysql/lib/mysql/libmysqlclient.so.12
  #4 0x0806ceac in checkhelo_mysql ()
  #5 0x0806d757 in receivedHELO ()
  #6 0x0808ff30 in handlePlaintext ()
  #7 0x0806e0e8 in handleMessage ()
  #8 0x0806aeee in execute_messages_from_mysql ()
  #9 0x0808eba3 in threadMain ()
  #10 0x4008c2b6 in start_thread () from /lib/tls/libpthread.so.0
  (gdb) thread 2
  [Switching to thread 2 (Thread 1078291648 (LWP 4446))]#0 0xffffe002 in ?? ()
  (gdb) ba
  #0 0xffffe002 in ?? ()
  #1 0x4008c2b6 in start_thread () from /lib/tls/libpthread.so.0
  (gdb)

Je moet het van onder naar boven lezen. Eerst wordt start_thread aangeroepen. Deze procedure roept threadMain() aan. Hierna wordt mijn execute_messages_from_mysql () aangeroepen, etc.

Na wat trail en error heb ik bovenstaande fout opgelost. Alleen heb ik nu een CRC error. Ik weet dat je altijd een blob veld moet escapen. Ik zal morgen uitzoeken waar het fout gaat. Ik zie geen unexcape routines in MySQL, dus zal wel automatisch goed komen bij het uitlezen van een blobveld.

De vriendelijke groet Jan Marco

[alkema_jm]

Hoi RGJ,

Ben erg blij, want het lijkt goed te werken. Erg mooi te zien dat hij aldoor probeert bij te werken.

Ik zie geen hoge CPU waarden meer. M.i. kwam dit door “out of sync” problemen.

Wel leuk te vermelden dat de gemiddelde CPU gebruik van Mysql hoger is dan foonsearchd.

Je krijgt berichten (packets) binnen. Eigenlijk kan in 1 packet meerdere berichten (helo, ping, pong, etc) zitten. Als de thread de packets binnen haalt zie je dat door een nieuwe record en het status veld is “NULL”. Tot messagepackSN 5549 is dus verwerkt in onderstaand voorbeeld:

| date | time | messagepackSN | senderidentity_asci | senderip | crc | status |
| 20041222 | 17:49:07 | 5546 | JB5IQ1BTA8Q5PKP8653ULKGSRQO2J90E | 82.165.43.81 | 908315629 | proccessed |
| 20041222 | 17:49:11 | 5547 | V0N2PUGNMU61KPPU0H606H3T011Q1600 | 128.10.19.51 | 1905001393 | proccessed |
| 20041222 | 17:49:16 | 5548 | 4EAPJG80RVIERS0H4LGHRPAENBF0S9G2 | 217.186.46.163 | 2633206437 | CRC_error |
| 20041222 | 17:49:18 | 5549 | B02G5722N6HLQPU73NC7SNHKJ2ABQS8U | 24.27.170.193 | 3792665755 | CRC_error |
| 20041222 | 17:49:22 | 5550 | 5TKR5SQ8T1AVQT7E4441941LTNDCUHSF | 128.210.189.80 | 3386723508 | NULL |
| 20041222 | 17:49:22 | 5551 | RRKH64OMJVEDM7320RD66FMBFRFTPPTC | 82.64.29.147 | 2073191073 | NULL |
| 20041222 | 17:49:23 | 5552 | B02G5722N6HLQPU73NC7SNHKJ2ABQS8U | 24.27.170.193 | 3618283537 | NULL |
| 20041222 | 17:49:26 | 5553 | B02G5722N6HLQPU73NC7SNHKJ2ABQS8U | 24.27.170.193 | 2860050168 | NULL |
| 20041222 | 17:49:27 | 5554 | V0N2PUGNMU61KPPU0H606H3T011Q1600 | 128.10.19.51 | 2330709121 | NULL |

De verwerkthread is bezig geweest en heeft messagepackSN 5550 en hoger verwerkt. Deze thread kijkt eerst of het bericht goed is door naar de CRC te kijken. Indien CRC goed is dat verwerkt hij het bericht.

| date | time | messagepackSN | senderidentity_asci | senderip | crc | status |
| 20041222 | 17:49:22 | 5550 | 5TKR5SQ8T1AVQT7E4441941LTNDCUHSF | 128.210.189.80 | 3386723508 | CRC_error |
| 20041222 | 17:49:22 | 5551 | RRKH64OMJVEDM7320RD66FMBFRFTPPTC | 82.64.29.147 | 2073191073 | proccessed |
| 20041222 | 17:49:23 | 5552 | B02G5722N6HLQPU73NC7SNHKJ2ABQS8U | 24.27.170.193 | 3618283537 | CRC_error |
| 20041222 | 17:49:26 | 5553 | B02G5722N6HLQPU73NC7SNHKJ2ABQS8U | 24.27.170.193 | 2860050168 | CRC_error |
| 20041222 | 17:49:27 | 5554 | V0N2PUGNMU61KPPU0H606H3T011Q1600 | 128.10.19.51 | 2330709121 | CRC_error |
| 20041222 | 17:49:31 | 5555 | 7IFMNBOJ4OITDKEHNNM6E54J3ABJOHHG | 130.208.220.221 | 3361906020 | CRC_error |
| 20041222 | 17:49:31 | 5556 | JB5IQ1BTA8Q5PKP8653ULKGSRQO2J90E | 82.165.43.81 | 1183593977 | proccessed |
| 20041222 | 17:49:31 | 5557 | 4EAPJG80RVIERS0H4LGHRPAENBF0S9G2 | 217.186.46.163 | 3741017184 | CRC_error |
| 20041222 | 17:49:32 | 5558 | B02G5722N6HLQPU73NC7SNHKJ2ABQS8U | 24.27.170.193 | 1881765830 | proccessed |

Morgen ga ik beginnen met het omzetten naar Visual studio. Hierna ga ik een “SQL query berichtje” maken en testen tussen mijn Windows PC en Linux server,

De vriendelijke groet Jan Marco

P.S. Ik denk dat het erg goed is om eerst de berichten in MySQL te dumpen en ze later te verwerken. N.B. Gnunet heeft 16 geheugenplekken en als die vol zijn dan gooit hij ze weg. De verwerking zou ook op prioriteit gedaan kunnen worden, dus sommige packets eerder verwerken dan anderen. Bijvoorbeeld een online achtige applicatie.

Andere verwerkingsvolgorde kan m.i. gemakkelijk in SQL geprogrammeerd worden.

[alkema_jm]

Hoi RGJ,

De versie van gisteren crashte. De huidige versie (foonsearchd-0.11.zip) werkt al vele uren goed bij mij op Linux. Lijkt redelijk stabiel te werken.

Als ik deze functionaliteit goed heb kunnen poorten naar Windows ben ik al erg blij.

18397 messagepack records zijn binnengekomen. 46695 (mysql) database calls zijn uitgevoerd. Het is altijd belangrijk om de performance aspecten in de gaten te houden. Door gebruik te maken van een database wordt dit wel transparanter te onderzoeken.

Momenteel bezig met het poorten naar Visual studio. Ik heb eerst alle procedures eruit gegooid die niet snel gepoort kunnen worden. Wat over blijft probeer ik eerst te kunnen compileren.

Ik zal scherp kijken of ik “de uitval” wel nodig heb. Ik wil eerst een stabiele framework in de lucht krijgen. Nice to have kan later wel worden aangekopppeld.

De vriendelijke groet Jan Marco

[alkema_jm]

Hoi RGJ,

Ik heb net het idee gekregen om de helo, ping en pong, etc. berichten uiteindelijk in het SQL formaat bericht te stoppen. Dus Lekker flexibel —)

Wat ik nu doe is een packet in mysql stoppen bij binnenkomst. De verwerkingsthread haalt het packet er weer uit en verwerkt het door het in een vrij vaste structuur te stoppen.

Is het berichtje bijvoorbeeld een Helo dat gaat hij weer in MySQL kijken of hij al zo’n helo heeft.

Ben net begonnen met het opruimen van de (AFS) code. Visual studio geeft een error bij 65k aan source code regels. Wat ik nu heb is m.i. al voldoende om het uit te bouwen.

De helft van de huidige berichten (messagepacks) geeft een CRC error. Dit komt omdat de bytes van een integer in verschillende volgorde gerepresenteerd worden bij verschillende Linux machines. Als je een CRC op een SQL query zet heb je daar niet zo’n last meer van —)

Het poorten van de code gaat redelijk. Ik gebruik de compiler optie #ifdef _MSC_VER om de Windows specifieke code in te zetten. Daarnaar heb ik een define MUSTFIX opgenomen in de code. In het MUSTFIX gebied staat de code die nog gepoort moet worden naar Windows.

Morgen ga ik code uit http://sources.redhat.com/pthreads-win32/ halen voor de Windows poort. Leuk te vertellen dat ze net een fout (deadlock) hebben gevonden in semaphore_up_(). Ze vonden het vreemd waarom dit niet eerder bekend is geworden.

Straks ga weer verder met het opschonen van de code. Ik probeer het wat minder complex te maken.

De vriendelijke groet Jan Marco

P.S. Gisteren ging hij na een bepaalde periode weer op 100% CPU zitten. Dus er zit nog wel een fout in. Op den duur vind ik deze fout wel.

[alkema_jm]

Hoi RGJ,

Ik heb

Emule, Emuleplus, Filezilla, Filezillaserver, putty en wget gedownload.

Foonsearch en wget hebben openssl nodig, dus op de volgende site staat de openssl binaries:

OpenSSL for Windows

In de bin directory staat:

Libeay32.dll en libssl32.dll.

RGJ, Hoe krijg ik openssl in ‘mijn’ programma? Normaliter moet je een dll laden en de procedure adressen uit de dll gaan laden. Lijkt mij dat dit al door iemand is gedaan.

Op http://allserv.ugent.be/~bpuype/wget/ staat wel wat info om het te compileren. Krijg je m.i. bovenstaande dll’s.

De vriendelijke groet Jan Marco

[alkema_jm]

Hoi RGJ, Zelf al een antwoord gevonden op mijn vraag–)

Ik zie in AsyncSslSocketLayer.cpp van FileZilla de loaddll structuur in procedure “CAsyncSslSocketLayer::InitSSL()”

Ik ga morgen eerst FileZilla proberen werkend te maken. Hierna meer kennis hoe ik openssl moet gaan gebruiken.

De vriendelijke groet Jan Marco

[alkema_jm]

Hoi RGJ,

Als je Filezilla compileert zal je ook OptionsTransferCompressionPage.cpp in het project moeten doen, anders krijg je een rare foutmelding.

Ik heb nog 7 unresolved externals bij het compileren van FileZilla:

1. ControlSocket.obj : error LNK2019: unresolved external symbol _idna_to_ascii_8z

2. TransferSocket.obj : error LNK2019: unresolved external symbol _inflateEnd

3. TransferSocket.obj : error LNK2019: unresolved external symbol _deflateEnd

4. TransferSocket.obj : error LNK2019: unresolved external symbol _inflate

5. TransferSocket.obj : error LNK2019: unresolved external symbol _deflate

6. TransferSocket.obj : error LNK2019: unresolved external symbol inflateInit2

7. TransferSocket.obj : error LNK2019: unresolved external symbol deflateInit2

Ad 1) Zal ik de source code uit GNU IDN Library - Libidn - GNU Project - Free Software Foundation gaan halen.

Ad 2 t/m 7 kan je de source uit zlib van MySQL of Emule gaan halen.

De vriendelijke groet Jan Marco

[alkema_jm]

Hoi RGJ,

Omdat ik toch met zip bezig ben denk ik aan om de SQL query te zippen in het p2p_PROTO_SQL (identifier = 9) bericht. Hierna mogelijk encrypten.

Het sturen van een Helo naar een andere peer wordt dan gewoon het zippen van een SQL statement en daarna optioneel encrypten met de public key van die andere peer:

“INSERT INTO helo (date,time,header_asci,header_size,header_requestType,protocol,senderip,senderport,MTU,publicKey_len,publicKey_sizen,publicKey_padding,expirationTime,senderAddressSize,PublicKey,senderIdentity,signature,LastTimeSeen) VALUES (%s,’%s’,%u,%u,%u,’%s’,%d,%u,%u,%u,%u,%u,%u,’%s’,’%s’,’%s’,%llu);"

De parameters (%s) natuurlijk wel even invullen met de specifieke waarden.

Indien je een PING SQL statement van een andere peer krijgt zet je de reactie (PONG bericht) in de messagesentpack tabel.

De WorkLoadManager (WLM) bestuurt het geheel. De WLM is in foonsearchd threadMain () en zal de binnengekomen berichten gaan verwerken door de berichten uit te voeren. Mogelijke antwoorden voor andere peers in de messagesentpack tabel zetten.

De vriendelijke groet Jan Marco

[alkema_jm]

Hoi RGJ,

Ben bezig met drie programma-tjes (zlib, pthreads en isda), . Deze zijn nodig om Filezilla te compileren en Foonsearchd te kunnen poorten op Windows m.b.v. Visual Studio.

Filezilla heeft Local site (“localfilesystem” database o.i.d.) en Remote site. Ik ga proberen om dit indirect te maken. Dus vanuit de database dit laten zien. Het laten zien wordt dan generiek. Het maakt niet uit of je Helo, Messagepack, postcode, of localfilesystem laat zien. Het vullen van localfilesystem doe je in een thread op de achtergrond. Antinimda project heeft wel code om dit te maken.

Ik denk ook aan om “SHOW TABLE STATUS FROM foondump2004;” elk uur uit te laten voeren en output in een statusdatabase zetten. Kan je in de tijd zien of de database aan het groeien is.

De vriendelijke groet Jan Marco

[alkema_jm]

Hoi RGJ,

Van de 27 external openssl variabelen kan ik 3 match met CasyncSslSocketLayer.cpp van FileZilla. Zie appendix A voor de details.

Ik ga nu proberen om de rest aan te koppelen (27 – 3=24 stuks).

Ik heb een 2-tal threads uitgezet. De ene was een extra tcp-port voor het ophalen van statistisch informatie door de cliënt. M.i. beter om dit via de database of via het protocol te laten lopen. De andere was de Anonieme File Server (AFS) request thread. Ik denk dat de laatste er voor zorgde dat soms het systeem op 100% CPU utilization kwam.

De gedachte achter gnunet is dat je een hoofd framework (helo, ping, pong, etc) hebt en daarop positioneer je een gnunet applicatie. Dit doe je door het laden van libraries. Het dynamisch laden van libraries is m.i. wel platform afhankelijk. Het is m.i. wat moeilijker te poorten naar andere platforms. Eigenlijk heb ik de logica van het hoofd framework instant gehouden. Het maken van een applicaties op deze framework zie ik meer als het maken van andere (SQL) berichten.

De AFS thread werkte gelijksoortig aan hoofd verwerkingthread (ping, pong, helo berichten), dus m.i. is het beter om de hoofd thread alle berichten in de messagepack queue te laten zetten en proberen te verwerken door het executeren van de (SQL) berichten.

Het poorten van de tread/semaphore code heb ik ook gelijktijdig mee bezig.

De vriendelijke groet Jan Marco

P.S. De FileZilla code is best mooie source code.

Appendix A: Mapping van openssl variabelen op CasyncSslSocketLayer.cpp:
_BN_bin2bn
_BN_bn2bin
_BN_num_bits -----> pBN_num_bits
_ERR_error_string -----> pERR_error_string
_ERR_free_strings
_ERR_get_error -----> pERR_get_error
_ERR_load_crypto_strings
_EVP_bf_cfb
_EVP_CIPHER_CTX_cleanup
_EVP_DecryptFinal
_EVP_DecryptInit
_EVP_DecryptUpdate
_EVP_EncryptFinal
_EVP_EncryptInit
_EVP_EncryptUpdate
_RAND_bytes
_RAND_set_rand_method
_RAND_SSLeay
_RIPEMD160
_RSA_free
_RSA_generate_key
_RSA_new
_RSA_private_decrypt
_RSA_public_encrypt
_RSA_sign
_RSA_size
_RSA_verify

[alkema_jm]

Hoi RGJ,

Ben nu bezig om de MFC specifieke zaken uit CAsyncSslSocketLayer.cpp om te zetten naar “normale” C-code. Best veel unicode achtige zaken zitten er in. In Unicode, MBCS and Generic text mappings - CodeProject staat wat uitgelegd over unicode.

De demon (foonsearchd.exe|foonsearchd) wil ik geen afhankelijkheid met MFC hebben en voor de GUI (foonsearch.exe) maakt mij dat niet uit. De interface ligt bij mij op database level.

De demon code zal op Linux en Windows moeten kunnen compileren en werken. Daarentegen zal de GUI vooralsnog alleen maar op Windows werken.

De vriendelijke groet Jan Marco

[alkema_jm]

Hoi RGJ,

Ik heb het “openssl-dll-laad-gedeelte” uit FileZilla gehaald. libeay32.dll en ssleay32.dll worden hierbij geladen.

Ik heb wel een probleem met het laden van ERR_error_string i.p.v. pERR_error_string. Ik heb het opgelost door in Windows een andere variabele (namelijk pERR_error_string) te gebruiken dan in Linux (ERR_error_string). Zie ook appendix A voor de details.

Ik denk dat dit op te lossen is door minder openssl include files te gebruiken in de Windows versie of te kijken bij andere Windows projecten “hoe die dat doen”.

Ik zit ook stevig om de thread/semafore code in Windows gelijk te trekken met de Linux versie.

De CPU fout zit er nog in. Ik denk toch dat met de afhankelijkheid in de Mysql code te maken heeft. Zal wel semaphore programmering worden.

De vriendelijke groet Jan Marco

Appendix A:

typedef char (*tERR_error_string) (unsigned long e, char *buf);

static tERR_error_string pERR_error_string;

pERR_error_string = (tERR_error_string) GetProcAddress(m_hSslDll2, “ERR_error_string”);

#ifdef _MSC_VER
printf(“03:decryptHostkeyOPENSSL error=%s!\n”, pERR_error_string(pERR_get_error(), NULL));
#else
printf(“03:decryptHostkeyOPENSSL error=%s!\n”, ERR_error_string(ERR_get_error(), NULL));
#endif

[alkema_jm]

Hoi RGJ,

Ben nu bezig met het Windows Threads/semapfore gedeelte. Gaat best redelijk. Kost wel “wat” tijd om in dit onderwerp in te leven.

De Windows variant wordt in eerste instantie anders dan de Linux versie. Ik haal source uit http://sources.redhat.com/pthreads-win32/

Ik denk dat ik geen moeilijke problemen meer tegenkom met het poorten naar Visual Studio,

De vriendelijke groet Jan Marco