After fixing an internal application bug concerning data length wrapping
(179k trying to be held in a u_short), I then hit another problem with
the data not being sent over a tcp connection correctly. In a function
where send() was being called the full 179k of data was being seen. The
server side of the connection was however rejecting the data (checksum
mismatch).
The reason for this was send() sending the first 32k over and over again
until the full 179k was sent over the connection. The send function
accepts an int as the length and i can not see any documentation to say
there is a 32k limit. The send function however returns with the amount
of data transfered 179k (although it has repeatedly sent the first 32k).
This has been fixed by sending the data in chucks of 32k to the send()
function. Just thought it was worth mentioning.
Len.
“Len Meakin” <len.meakin@cirrustesting.com_REMOVE> wrote in message
news:cvkui6$r24$2@inn.qnx.com…
Len Meakin wrote:
After fixing an internal application bug concerning data length wrapping
(179k trying to be held in a u_short), I then hit another problem with
the data not being sent over a tcp connection correctly. In a function
where send() was being called the full 179k of data was being seen. The
server side of the connection was however rejecting the data (checksum
mismatch).
The reason for this was send() sending the first 32k over and over again
until the full 179k was sent over the connection. The send function
accepts an int as the length and i can not see any documentation to say
there is a 32k limit. The send function however returns with the amount
of data transfered 179k (although it has repeatedly sent the first 32k).
This has been fixed by sending the data in chucks of 32k to the send()
function. Just thought it was worth mentioning.
Len.
I recall this being a bug in the stack. I don’t rember in which version
this bug was in nor in what version it was fixed
chucks == chunks