Binärdaten per CAsyncSocket

Hallo,

ich sende ein Formular per POST an einen http Server, das klappt auch, aber leider sobald ich eine Datei mitschicken will welche größer als ca. 35 Kbytes ist geht es nicht mehr.

char* Buffer=new char [Dateigr];

datei.read(Buffer,Dateigr);

this->Send(Buffer,Dateigr);

Auch der Versuch mit einer Whileschleife welche pro Durchlauf 1000 bytes verschickt geht nicht wirklich. Ich sitze nun schon seit 3 Tagen an dem Problem.
Ich habe gerade gemerkt, wenn ich ein "Sleep(x)" in die Schleife einbaue funktioniert es ... das ist aber nicht im Sinne des Erfinders, ich war davon ausgegangen, das Send blockierend wartet wie in der MSDN geschrieben ..., hat jemand eine Lösung dafür?

(Ich nutze VC++ 6.0 und dieser Code ist in einer Win32 DLL mit MFC Unterstützung)

MFK

Mounty schrieb:

ich war davon ausgegangen, das Send blockierend wartet

Die entscheidende Eigenschaft von CAsyncSocket ist, dass da nichts blockiert. Deswegen heißt die Klasse so.

Hmm und hättest du eine Idee wie man das lösen kann? CSocket verwenden? Wobei ja CSocket sich von CAsyncSocket ableitet

Ok, nachdem ich alles auf CSocket umgeschrieben habe funktioniert es.

Danke fürs lesen

Im Internet steht das CSocket ganz böse sei. :o

*seuftz* Ich muss leider nochmal eure Hilfe ersuchen, leider hat die Suche im Netz keine wirkliche Antwort ergeben.

Mein Projekt ist fast fertig, aber sobald ich von Debug auf Release umstelle und compiliere funktioieren weder CSocket(.connect) Verbindungen noch ein simples File.open, sobald ich es wieder als Debug compiliert habe geht alles wieder.

Die Einstellungen von Release und Debug sind unverändert, seit der Installation von VS 6

MFK

Die häufigste Ursache für so ein Verhalten ist schlampige Progammierung: Uninitialisierte Variablen, Bereichsüberschreitung bei Arrays, falsche oder fehlende Threadsynchronisierung usw.

Hallo MFK,

danke, das hat mich auf den richtigen Weg gebracht. Der Inhalt einer Variable welche von dem Programm an meine DLL übergeben wurde kam im Release irgendwie verstümmelt an (weshalb Dateinamen und http Adressen nicht stimmten), das konnte ich beheben.

Eine Sache konnte ich bisher leider noch nicht lösen:
Die Software verwendet eine Art Platzhalter welche ich erfragen muss, im Debug funktioniert folgendes:

CString DLH::Aufloesen(CString var)
{
char* buff=new char[100000];	
CString t="";
long v;
v=ExecuteCallback("Subst",var,-1,0,buff);

for(long i=0;i<v;i++)
{
t.Insert(i,buff[i]);
}

return t;
}

Im Debug funktioniert es, dass in "buff" der gesuchte Wert steht und "v" ist die Länge.
Im Release enthält "buff" immer "x[]6" der Rückgabewert "v" stimmt allerdings. ([] ist ein geschlossenes Viereck, also wohl ein char der nicht darstellbar ist)

die Callbackfunktion (und die funktioniert auch solange ich den "ReturnString" nicht benötige)sieht so aus:

long DLH::ExecuteCallback(const char *FuncName, const char *Para, const int ParaLen, const int Flags, const char* ReturnString)
 {
//Callbackfunktion

         typedef long (__stdcall *FUNCPTR)(const char* a,const char* b,const int c,const int d, const char* e);
         FUNCPTR vbFunc;
		 vbFunc = (FUNCPTR)CallbackAddress;     
	return(vbFunc(FuncName,Para,ParaLen,Flags,ReturnString));

Ich habe diese Funktion aus der PureBasic Vorlage gebastelt da es kein c++ Beispiel gibt, wobei ich sagen muss ich hab mit PB nie was zu tun gehabt, die Software für welche das Plugin ist wurde in VB geschrieben.

Prototype.l cbCallback(FuncName$, Para$ = " ", ParaLen.l = -1, Flags.l = 0, ReturnString$ = " ")
  Global cbCall.cbCallback

Hallo nochmal,

ich konnte das Problem lösen.

Ich habe just4fun die 100.000 reservierten chars's mit Leerzeichen gefüllt, nun geht es oO

MFK

Mounty schrieb:

Ich habe just4fun die 100.000 reservierten chars's mit Leerzeichen gefüllt, nun geht es oO

Ist dir klar, dass du bei jedem Aufruf dieser Funktion 100.000 Bytes unwiderruflich leakst?

Hallo MFK,

Sollte die Variable sich nicht selbst "zerstören" bei Funktionsende, da diese ja nur lokal ist?

Bzw. mit delete müsste das auch eigendlich gehen.