I have a simple csharp custom webserver client using TcpListener and
AcceptSocket() to receive requests. This works flawlessy with HTTP GETs,
HTTP POSTs, but I have discovered that it is unable to get the POST data
from an AJAX call. The AJAX call is using YUI and is fine, as I can post to
an aspx page and read the posted data. In the custom webserver, I see the
request as sent but the posted data is empty.

Does anybody have any idea why data posted from AJAX would be different from
an HTTP POST? I can follow up with dupe code if necessary.

My mistake, it seems that there is a difference in the speed the request is
sent on the socket between the AJAX post and HTTP post. My socket reading
logic worked fine for other requests, but the buffer read/sleep logic needs
to be changed to handle the AJAX. I must be losing the data because the
socket is receiving faster than I am processing it.


"Stephen Brown" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I have a simple csharp custom webserver client using TcpListener and
>AcceptSocket() to receive requests. This works flawlessy with HTTP GETs,
>HTTP POSTs, but I have discovered that it is unable to get the POST data
>from an AJAX call. The AJAX call is using YUI and is fine, as I can post
>to an aspx page and read the posted data. In the custom webserver, I see
>the request as sent but the posted data is empty.
>
> Does anybody have any idea why data posted from AJAX would be different
> from an HTTP POST? I can follow up with dupe code if necessary.

You are correct in that I have a deeper issue. I have come to that
conclusion in testing the code.

Here is the root of my code which does the socket handling:


private string GetRequest(Socket oSocket) {
string sBuffer = "";
Byte[] asReceive = new Byte[oSocket.ReceiveBufferSize];
int i = oSocket.Receive(asReceive, asReceive.Length, 0);
sBuffer = Encoding.ASCII.GetString(asReceive, 0, i);

Thread.Sleep(10);
while (oSocket.Available > 0) {
asReceive = new Byte[oSocket.Available];
int nBytes = oSocket.Receive(asReceive, oSocket.Available, 0);
sBuffer += Encoding.ASCII.GetString(asReceive);
}

return sBuffer;
}

This was patched together from several examples which I now understand,
mostly by reviewing past posts by yourself, is likely bad code. It has been
working for several months until I discovered that I lose data sent via AJAX
posts, although I have found that upping the Thread.Sleep to 100 ms works
for my test cases. However, this is a major hack and only possibly delays a
bigger issue, as depending on an arbitrary wait time is obviously flirting
with danger.

I do not require asynchronous at this time. What would be the correct
method to determine if the socket has completed sending data?

-Steve



"Peter Duniho" <(E-Mail Removed)> wrote in message
news(E-Mail Removed)...
> On Mon, 13 Apr 2009 08:36:58 -0700, Stephen Brown <(E-Mail Removed)>
> wrote:
>
>> My mistake, it seems that there is a difference in the speed the request
>> is sent on the socket between the AJAX post and HTTP post. My socket
>> reading logic worked fine for other requests, but the buffer read/sleep
>> logic needs to be changed to handle the AJAX. I must be losing the data
>> because the socket is receiving faster than I am processing it.
>
> If your data receiving logic is dependent on the rate or latency of the
> response, you've probably got a more serious problem with the code.
>
> Without seeing the code, it's hard to say for sure. But the most common
> mistake people make is to think that they will receive the bytes in the
> same groups in which they were sent. This incorrect assumption results in
> reading partial responses, or in multiple responses being consolidated
> into a single receive, or some combination of the two.
>
> If your code makes any assumptions about exactly what bytes will be
> received for a given call to receive, you've got a bug. The only thing
> that TCP guarantees you is that if for a given byte you've received, that
> it was sent after every other byte your code has already received. That
> is, the bytes come in the same order in which they were sent. For any
> given call to a receive method, you can receive any number of bytes
> between 1 and the total bytes that have been sent so far but not yet
> received. It's up to your code to break the received bytes into some
> usable arrangement of bytes.
>
> Pete