java socket write error -> talking with asp.net

[Guest]

situation:
I'm uploading file to my application using a java applet sending the request
(the file) through socket to my asp.net page.
On my asp.net page, I've override the httpmodule to take in the request and
saves the file to disk (on the server).
My .net side works if I use a simple html file input and post it, I've read
in the uploaded request (multipart form), and reproduced it in the java
applet.
Everything works fine when I upload a file around 20kb, but anything bigger,
I get that socket write error on the java side.

Now from the .net side the request.ReadEntityBody(data, bufferSize); will
return 0, meaning it's not reading anything from the request, and on the java
side I get the socket error.

So, who's causing the connection abort? .NET? IIS? XP?

I've put in the <httpRuntime executionTimeout="1800"
maxRequestLength="524288" /> in web.config, so timeout shouldn't be the
problem, as the whole upload process will last less than a second before it
dies.

Any suggestions?

 

[Bruce Barker]

you have to write the code for ReadEntityBody. the default implementation
just returns a zero. if your handler want to call this routine, it should
override it and supply the code.

-- bruce (sqlwork.com)

 

[Guest]

yea...but it's returning 0 because there is no more to read...since the
socket connection has been aborted somehow.
other than that the readentitybody is functioning as it should.

I need to find out why the connection is aborted.

On a update note, I find that on a fresh new aspnet process, the upload goes
further, and following uploads will end at most at 48kb.
Then after I kill the aspnet process and upload again, it'll go beyond 48kb
again.

 

[Guest]

Update:
I've solve the problem on the java part now.

Problem now is with .NET's readentitybody returning 0 bytes read, even if
there's more things to be read.
I'm posting this on a new question, as the topic's changing.

 

[mensikd]

Hi,
In loop where you are reading data:

while(ms.Position < req.ContentLength)
{
bytesRead = worker.ReadEntityBody(buffer, buffer.Length);
ms.Write(buffer, 0, bytesRead);
}

realloate buffer for last reading. I've discovered that if you have
last e.g. 58 B for read in request, and you are reading to buffer
allocated to 100 B with code:

bytesRead = worker.ReadEntityBody(buffer, buffer.Length);

then (IMHO!!!!) system will wait for buffer.Length Bytes. So I
reallocate the buffer to the last of request data and everything goes
well - except of two days of lost time and de-ja vu, because I've
already solved this problem, but forget the solution very quickly...

Solution is in code below.

while(ms.Position < req.ContentLength)
{
bytesRead = worker.ReadEntityBody(buffer, buffer.Length);
ms.Write(buffer, 0, bytesRead);

newBufferSize = req.ContentLength - (int)ms.Position;
if(newBufferSize < BUFFER_SIZE && newBufferSize > 0)
buffer = new byte[req.ContentLength - ms.Position];
}

With best regard,
Ozon.

 

[mensikd]

And turn off tracing.
In web.config :
<trace
enabled="false"... >

Ozon

 

[Guest]

That's interesting...I found a solution...but couldn't explain it...
it has to do with my java side uploading the file...
right at the end of sending out the file section....before I write teh
footer to the file section of the multiform...I put in a delay....of
100ms.....
and magically....everything goes...
it would be nice if you can explain why that works for me.
I discovered this when I trace through my java code...and find that tracing
through the java works....but not if I run it normally...

 

[mdinant]

Interested in ASP.NET/Java

Hi there, I am new to this forum. I want to write a server application on ASP.NET, and write client code with Java. I was wandering if you could give me something to start with, or some tips/ideas.

Eventually I want to use the UDP protocol, because I am making real time games.
My webhosting wont install Apache, (they apologized)

I've read that it is/was possible to write a servlet on ASP.NET, but I just saw that microsoft doesnt do java anymore, so thats no option, (i think...)

Thanks for your time, Matthijs Dinant