Sub Menu
Suche

Last Online
In order to view the online list you have to be registered and logged in.



We are a free and open
community, all are welcome.

Click here to Register

Neues Antifake-System?

BeitragAuthor: Stulle » Di 11. Mai 2010, 18:21

na grundsätzlich geht das schon, da der hash (binär) der key ist und wir danach sortieren und suchen können. die länge die übergeben wird bei IsFake wird in der tat nicht verwendet. die richtige dateigröße der geprüften datei wird allerdings durchaus richtig erkannt, wenn man die änderungen wie oben geschrieben macht. also meine aktuelle vermutung wieso das funktioniert ist etwa so:

wir übergeben bsearch einen pointer zum hash array im speicher und in CmpFakeByHash_Lenght zwingen wir dann den pointer zum array in einen pointer zum struct, wobei wir dadurch auch gleich noch m_nFileSize in besagtem struct haben. wieso das funktioniert versteh ich aber auch nicht, da ich immer dachte, dass membervariablen einer klassen instanz durchaus wild im speicher verteilt liegen könnten. anscheinend ist es aber nicht so, so dass man aufeinanderfolgende, aber unabhängige membervariablen durchaus auf diese weise in ein struct zwingen kann.

naja, da mir nichts besseres einfällt werde ich das wohl als fix benutzen (müssen).

edit: on topic: immo wäre eine verbindung von webservice und fakes.dat sinnvoll. man kann über webservice reporten und abfragen und zusätzlich auf die .dat zurückgreifen um die server resourcen zu schonen durch unendlich viele einzelne anfragen. außerdem ist es komfortabler.

Stulle
Forenlegende
 
Beiträge: 1014
Registriert: So 5. Feb 2006, 09:55

BeitragAuthor: WiZaRd » Di 11. Mai 2010, 18:40

Hast du das mal probiert?
struct Fakes_Struct{
const uchar Hash[16];


Dass es GRUNDSÄTZLICH geht bezweifel ich nicht, alle Daten lassen sich binär darstellen. Die fehlende Größe ist bei dir wohl kein Prob weil doppelte Hashes (bisher) nicht vorgekommen sind - sollte das aber passieren, dann...

Normal springt jedoch die Funktion von einem Element des Arrays zum nächsten, wobei die Daten etwa so im Array liegen
<-- 0 --><-- 1 -->...<-- n -->
wobei jedes Element die Breite width hat. Da diese aber eben NICHT fest ist, weil ein CString unterschiedliche Länge haben kann, kann die Funktion normal auch nicht einfach via +X Bits zum nächsten Element springen und landet dann eben z.B. mitten in einer struct statt am Beginn. Ich nehme an dass es da noch weitere "Tricks" von V$ gibt, aber rein LOGISCH dürfte es nicht korrekt funktionieren.

Ich hab es bei mir btw. so gelöst:
static int __cdecl CmpFakeStruct(const void* pvKey, const void* pvElement)
{
const Fakes_Struct* find = *(Fakes_Struct**)pvKey;
const Fakes_Struct* pIPFilter = *(Fakes_Struct**)pvElement;

int comp = memcmp(find->Hash, pIPFilter->Hash, 16);
if(comp == 0)
comp = CompareNumbers(find->Length, pIPFilter->Length);
return comp;
}

Fakes_Struct* CFakecheck::FindItem(const uchar* uHash, const uint64& uLen)
{
Fakes_Struct* find = new Fakes_Struct(uHash, uLen, L"");
Fakes_Struct** ppFound = (Fakes_Struct**)bsearch(&find, m_fakelist.GetData(), m_fakelist.GetCount(), sizeof(m_fakelist[0]), CmpFakeStruct);
delete find;
if(ppFound)
return *ppFound;
return NULL;
}
...
bool CFakecheck::IsFake(const uchar* Hash2test, const uint64& Length)
{
return FindItem(Hash2test, Length) != NULL;
}

Kannst es ja mal adaptieren.
Bild

... 9 von 10 Stimmen im meinem Kopf sagen ich bin nicht verrückt... - die 10te summt die Melodie von TETRIS
Benutzeravatar
WiZaRd
Forenlegende
 
Beiträge: 3805
Registriert: Fr 7. Jan 2005, 19:28
Wohnort: The Realm of Magic

BeitragAuthor: Stulle » Di 11. Mai 2010, 18:51

ich sehe nicht wie das const das ändern sollte. das problem ist nicht das weiterleiten vom hash per se, der wird ja korrekt erkannt und verglichen, das problem ist bei mir gewesen, dass die länge des zu überprüfenden elements nicht gesetzt wurde.

was du da im unteren teil vorschlägst ist grundsätzlich die wohl saubere variante, wobei ich mich frage ob es funktioniert, denn der key ist ja kein struct sondern der hash. kann aber natürlich sein, dass ihm das egal ist, da ab dem ersten bit des structs gleich der hash anfängt. nun ist natürlich die gretchen frage, was ist sauberer und resourcen schonender? ich würde bald sagen meine lösung schont zumindest die CPU etwas mehr, da ich nicht zusätzlich speicher alloc für hash und length, sondern lediglich den hash noch mal im speicher behalte ein weiteres mal. sauberer wäre aber wohl dein anlauf. wobei sich mir auch noch die frage aufdrängt, gibt bsearch einen pointer auf einen pointer, der auf ein item im array zeigt wieder oder gibt er doch nur einen pointer auf einen pointer wieder, der auf dein find item zeigt, sollte es gefunden werden. meinungen?

Stulle
Forenlegende
 
Beiträge: 1014
Registriert: So 5. Feb 2006, 09:55

BeitragAuthor: WiZaRd » Di 11. Mai 2010, 19:05

Stulle hat geschrieben:ich sehe nicht wie das const das ändern sollte. das problem ist nicht das weiterleiten vom hash per se, der wird ja korrekt erkannt und verglichen, das problem ist bei mir gewesen, dass die länge des zu überprüfenden elements nicht gesetzt wurde.

Wie, das hat bei dir nicht funktioniert? Interessant... evtl. eben o.g. "Problem" und V$ 2008 behandelt diesen Fall endlich "korrekt".

wobei ich mich frage ob es funktioniert, denn der key ist ja kein struct sondern der hash.

Ich speichere natürlich structs in meiner Liste, daher muss ich auch nach einem Struct suchen.
nun ist natürlich die gretchen frage, was ist sauberer und resourcen schonender? ich würde bald sagen meine lösung schont zumindest die CPU etwas mehr, da ich nicht zusätzlich speicher alloc für hash und length, sondern lediglich den hash noch mal im speicher behalte ein weiteres mal. sauberer wäre aber wohl dein anlauf. wobei sich mir auch noch die frage aufdrängt, gibt bsearch einen pointer auf einen pointer, der auf ein item im array zeigt wieder oder gibt er doch nur einen pointer auf einen pointer wieder, der auf dein find item zeigt, sollte es gefunden werden. meinungen?

Das gibt einen Zeiger zurück der auf den Zeiger im Array zeigt.
Wegen Resourcen... hmm... ich hab es nu mal als Member deklariert - das löst das Problem mit der (De-)Allokation.

Fakes_Struct* CFakecheck::FindItem(const uchar* uHash, const uint64& uLen)
{
md4cpy(m_find->Hash, uHash);
m_find->Length = uLen;
Fakes_Struct** ppFound = (Fakes_Struct**)bsearch(&m_find, m_fakelist.GetData(), m_fakelist.GetCount(), sizeof(m_fakelist[0]), CmpFakeStruct);
if(ppFound)
return *ppFound;
return NULL;
}
Bild

... 9 von 10 Stimmen im meinem Kopf sagen ich bin nicht verrückt... - die 10te summt die Melodie von TETRIS
Benutzeravatar
WiZaRd
Forenlegende
 
Beiträge: 3805
Registriert: Fr 7. Jan 2005, 19:28
Wohnort: The Realm of Magic

BeitragAuthor: Stulle » Di 11. Mai 2010, 19:14

also das mit dem const am anfang habe ich nicht ausprobiert, aber ich sehe nicht wieso das etwas ändern sollte. der MD4 hash wird sich lokal sowieso nicht ändern, weder in den listen items, noch für eine instanz von AbstractFile.

das mit dem struct speichern ist hier ebenso.

nun eine member variable zu benutzen ist sicherlich schon mal besser von wegen des alloc overheads, doch ich frage ich mich ob das auch threadsafe ist. was wird passieren wenn zwei KAD suchen gleichzeitig SearchFile instanzen produzieren. dazu noch ne meinung?

Stulle
Forenlegende
 
Beiträge: 1014
Registriert: So 5. Feb 2006, 09:55

BeitragAuthor: WiZaRd » Di 11. Mai 2010, 19:21

Das ist ja egal, die Suche an sich, etc. findet doch komplett im Hauptthread statt.
Bild

... 9 von 10 Stimmen im meinem Kopf sagen ich bin nicht verrückt... - die 10te summt die Melodie von TETRIS
Benutzeravatar
WiZaRd
Forenlegende
 
Beiträge: 3805
Registriert: Fr 7. Jan 2005, 19:28
Wohnort: The Realm of Magic

BeitragAuthor: Stulle » Di 11. Mai 2010, 19:22

ergo kann jeweils immer nur eine datei gleichzeitig geprüft werden, ja?

Stulle
Forenlegende
 
Beiträge: 1014
Registriert: So 5. Feb 2006, 09:55

BeitragAuthor: WiZaRd » Di 11. Mai 2010, 19:29

logisch, aber das ist ja immer so, da der alte Code ja auf einen "lastHit" vertraut, der kann sich ja auch ständig ändern.
Bild

... 9 von 10 Stimmen im meinem Kopf sagen ich bin nicht verrückt... - die 10te summt die Melodie von TETRIS
Benutzeravatar
WiZaRd
Forenlegende
 
Beiträge: 3805
Registriert: Fr 7. Jan 2005, 19:28
Wohnort: The Realm of Magic

BeitragAuthor: Stulle » Di 11. Mai 2010, 19:34

stimmt auch wieder. naja, ich jag es gerad mal durch den compiler... peinlich wenn ich nun deine lösung nehme und dann mal nicht meinen namen unter ein fix setzen kann... X-D jk

edit: okay, es funktioniert, das const hab ich aber weggelassen, da es weiterer änderungen bedarf das einzusetzen... wenn es überhaupt funktioniert...

edit2: und noch mal offtopic, diesmal betreffs ASFU... hatte das ja schon mal angerissen. ich denke dein crash fix bezieht sich auf folgendes:
Code: Alles auswählen
                     theApp.emuledlg->sharedfileswnd->SendMessage(WM_COMMAND, IDC_RELOADSHAREDFILES); //>>> WiZaRd::FiX! - Don't access the main thread from within a thread

jedoch verstehe ich nicht so recht wo da das problem ist. was wolltest du damit noch mal fixen? ich hatte noch *nie* probleme mit der zeile code^^

Stulle
Forenlegende
 
Beiträge: 1014
Registriert: So 5. Feb 2006, 09:55

BeitragAuthor: WiZaRd » Di 11. Mai 2010, 20:22

Genau das ist es.
Ich hatte mit dem beba rumhantiert, weil TuX da Crashes hatte... folgendermaßen "verlässlich" reproduzierbar:
Windows Temp-Ordner freigeben, ein wenig in den Shared Files rumklicken usw., zurück zum Server-Log und nach einer Weile: CRASH
Das Problem ist ganz einfach dass du aus einem Thread heraus auf die SharedFiles zugreifst und die sich somit ändert während andere Threads (der Hauptthread) weiterhin darauf zugreifen (können) - wenn das der Fall ist, dann ist das Verhalten unvorhersehbar und führt eben mitunter zum Crash, daher sorge ich durch das SendMessage dafür, dass der Reload im Hauptthread stattfindet und damit ist das Problem behoben.
Bild

... 9 von 10 Stimmen im meinem Kopf sagen ich bin nicht verrückt... - die 10te summt die Melodie von TETRIS
Benutzeravatar
WiZaRd
Forenlegende
 
Beiträge: 3805
Registriert: Fr 7. Jan 2005, 19:28
Wohnort: The Realm of Magic

VorherigeNächste

Zurück zu Entwicklung

Wer ist online?

Mitglieder: Bing [Bot], Google [Bot]

cron