C-Sockets-Keine Übertragung von Daten ab bestimmter Packetgröße

Hallo,

mache derzeit was mit Sockets unter C, funktioniert auch soweit, aber spaßeshalber habe ich mal schauen wollen, ab welcher Datenmenge nicht mehr alle Daten aufeinmal versendet werden.
Bis ca. 80000 Byte versendet er alles aufeinmal(Habe nur einen einzigen Sendevorgang), darüber macht er dann nichts mehr, d.h. die send()-Funktion gibt -1 zurück, statt irgendeiner Datenmenge.

Ich programmiere das gerade unter Windows XP mit Codeblocks und GNU GCC, dachte bei irgendwas um die 1 Kilobyte würde nur noch ein Teil der Daten versendet werden?! Und wieso macht er irgendwann gar nichts mehr?(hatte den Fall bei 800.000 Byte) Hatte eben angenommen er würde automatisch dann soviel verschicken, wie er kann?!

Ist zwar für mein eigentliches Programmierziel nicht so wichtig, aber es interessiert mich, danke für eure Antworten

knivil

Der Fehler liegt wahrscheinlich auf deiner Seite.

Verstehe ich jetzt nicht so ganz, was meinst du genau?
Ich hab nur versucht rauszufinden, ab welcher Grenze er die Daten nicht mehr in einem Rutsch verschickt. Gibt aber irgendwie diese Grenze nicht oO

wenn -1
dann

If no error occurs, send returns the total number of bytes sent, which can be less than the number requested to be sent in the len parameter. Otherwise, a value of SOCKET_ERROR is returned, and a specific error code can be retrieved by calling WSAGetLastError.

knivil hat dir den rest ja schon erklärt.
rtfm!

Ok, ok, tut mir leid^^ Ich schau morgen dann nach, danke sehr

Belli

snatchung_sock schrieb:

wenn -1
dann

If no error occurs, send returns the total number of bytes sent, which can be less than the number requested to be sent in the len parameter. Otherwise, a value of SOCKET_ERROR is returned, and a specific error code can be retrieved by calling WSAGetLastError.

Ja, RTFM!
Was Du hier zitierst, gilt nur für Sockets im nonblocking Modus. Ein Socket im blocking Modus (Standard) sendet entweder alles, oder nichts.

EOP

Belli schrieb:

snatchung_sock schrieb:

wenn -1
dann

If no error occurs, send returns the total number of bytes sent, which can be less than the number requested to be sent in the len parameter. Otherwise, a value of SOCKET_ERROR is returned, and a specific error code can be retrieved by calling WSAGetLastError.

Ja, RTFM!
Was Du hier zitierst, gilt nur für Sockets im nonblocking Modus. Ein Socket im blocking Modus (Standard) sendet entweder alles, oder nichts.

A common error. Den hier schon verschiedene Leute gepostet haben, um mich zu belehren.

Tut's eben nicht unbedingt. Ist einfach so.
Benutze eine Schleife.

Belli

EOP schrieb:

Tut's eben nicht unbedingt.

MSDN schreibt dazu:
If no buffer space is available within the transport system to hold the data to be transmitted, send will block unless the socket has been placed in nonblocking mode. On nonblocking stream oriented sockets, the number of bytes written can be between 1 and the requested length, depending on buffer availability ...

und ich habe bei zahlreichen Tests und Experimenten in der Vergangenheit genau das bestätigt gefunden.
send verhält sich da übrigens anders als recv. recv muss in der Tat in einer Schleife ausgeführt werden, bis die erwartete Anzahl von Byte gelesen werden konnte - auch auf einem blockierenden Socket.

heho, ich bins nochmal.
ich kapere meinen Thread mal für ein praktisches Problem das ich derzeit habe:

Ich programmiere auf RTOS-UH derzeit eine TCP-Verbindung auf einem Roboter zu einem danebenstehenden PC. Dabei richtige ich einen passenden Socket ein und übertrage Daten zu genanntem PC.
Folgendes passiert nun:
Die Verbindung wird erstellt, ich kann zweimal Daten übertragen(derzeit testweise einfach nur einen Buchstaben) und danach bricht die Verbindung ab. Auf dem Roboter
ist der genutze Socket weiterhin aktiv, d.h. ungleich -1.
Der Fehlercode auf dem PC gibt mir "Connection closed by peer" aus, was heißen könnte das eine Firewall den Datenverkehr blockiert(es liegt ein Router dazwischen, welcher eine aktive Firewall haben könnte, passwort liegt leider noch nicht vor, daher kann ich das noch nicht prüfen).
Jetzt erstmal die Frage: Kann das überhaupt sein, das eine Firewall erst nach kurzem Datenverkehr eingreift? Kommt mir doch reichlich seltsam vor.
Dann hätte ich leider auch gerade keine Idee wieso die Verbindung abbricht, es gibt noch zwei weitere Tasks die via UDP Daten an den PC verschicken, mit denen hat meine Task eigentlich überhaupt keinen Kontakt, aber vielleicht hakt es ja hier irgendwie, das meine Task die anderen beiden blockiert oder ähnliches.

Ich denke letzteres ist der Fall, aktiviere ich nämlich die TCP-Task vor den UDP-Tasks so gibt es in diesen einen Assert-error, der bei umgekehrter aktivierunsreihenfolge nicht auftritt(was mir reichlich seltsam vorkommt).

Bei folgender Zeile gibt es einen Error:
(C tags gehen irgendwie nicht, sorry)

s_udp_sender *s = udp_sender;
ASSERTRETURN_RUNTIME(s);<-- Fehler, normalerweise aber nicht

Meine TCP-Initialisierung und Nutzung:

Init:
bool LogInit(void)
{
short Port = PORT_PC;//8000
inet.sin_family = AF_INET;
inet.sin_addr.s_addr = inet_addr(IP_PC);// PC IP
inet.sin_port = htons(Port);
mysocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
if(connect(mysocket,(struct sockaddr*)&inet,sizeof(inet)) == -1)//==error
{
syslogf(LOG_WARN,"Fehler beim connecten");
return false;
}
return true;
}

Nutzung:

void DatenLogger(void)
{
char test[2] = {'c','\0'};
int len = 0;
len = send(mysocket,test,sizeof(char)*2,0);
syslogf(LOG_INFO,"Ich bin aktiv, socket = %d",mysocket);
}

Falls wer eine Idee hat(RTOS-UH ist leider nicht so verbreitet wie es scheint), wäre ich unendlich dankbar.

Hat sich geklärt, der Fehler lag daran, dass man den Socket in der Task erstellen muss.