HTTP Webserver - tcp thread issues

Dave wrote:

Hi,

I have been using several http server code examples from the web,
include one from msdn, and I can't seem to get a simple http server
thread working. I can connect the server successful using IE6 and
following url: http://127.0.0.1:5050
But when I attempt a second connect the windows symbol in the upper
right corner of ie starts in motion and nothing happens it just sits
there waiting for a response. The code also behaves very strangely
when I try to debug it, it will jump out of the serverThread
function in the middle of the stream.read loop and not return any
exceptions, I'm really lost on this one. The code also really seems
to stumble when I use IE's refresh button rather than typing in the
URL if you can believe it.

I have included the class in question below stripped to the bone.
Any feedback would be appreciated.

[...]

That's a singlethreaded implementation -- the main server thread should
spawn a new thread for each request accepted. Check out the Cassini web
server at www.asp.net.

Cheers,
--
Joerg Jooss
jo*********@gmx.net

Thanks Joerg,

Cassini looks like it will be very helpful, it is definitely a more complete
package than any of the examples I have come across to date, but I'd still
like to understand why my simple example doesn't work as expected before
getting into more complex examples. Even though it is single threaded
shouldn't the listener make itself available again once it has finished
processing a request? I'd also like to try to understand why it is not
consistently serving up the first request.

Thanks,
Dave

"Joerg Jooss" <jo*********@gmx.net> wrote in message
news:uy*************@tk2msftngp13.phx.gbl...

Dave wrote:

Hi,

I have been using several http server code examples from the web,
include one from msdn, and I can't seem to get a simple http server
thread working. I can connect the server successful using IE6 and
following url: http://127.0.0.1:5050
But when I attempt a second connect the windows symbol in the upper
right corner of ie starts in motion and nothing happens it just sits
there waiting for a response. The code also behaves very strangely
when I try to debug it, it will jump out of the serverThread
function in the middle of the stream.read loop and not return any
exceptions, I'm really lost on this one. The code also really seems
to stumble when I use IE's refresh button rather than typing in the
URL if you can believe it.

I have included the class in question below stripped to the bone.
Any feedback would be appreciated.

[...]

That's a singlethreaded implementation -- the main server thread should
spawn a new thread for each request accepted. Check out the Cassini web
server at www.asp.net.

Cheers,
--
Joerg Jooss
jo*********@gmx.net

News" <nospam> wrote:

Thanks Joerg,

Cassini looks like it will be very helpful, it is definitely a more
complete package than any of the examples I have come across to
date, but I'd still like to understand why my simple example doesn't
work as expected before getting into more complex examples. Even
though it is single threaded shouldn't the listener make itself
available again once it has finished processing a request? I'd also
like to try to understand why it is not consistently serving up the
first request.

Well, it should. After looking at your code again, there are still a
couple of issues that need to be taken care of:

1. Utter lack of exception handling ;-) This is quite dangerous anyway,
but since 99.9% of all exceptions are to be expected in the main server
thread, a simple try/catch in main() won't help.

2. Review the docs for TcpClient and NetworkStream on MSDN. For example:
"You must close the NetworkStream when you are through sending and
receiving data. Closing TcpClient does not release the NetworkStream."

Unfortunately, MSDN's own samples are sometimes wrong if this is true. I
guess not adhering to those guidelines may have weird side effects.

3. If you know Java (or better its java.net package), a multithreaded
HTTP server can be found at
http://www.devhood.com/tutorials/tut...utorial_id=396
&printer=t

ServerSocket becomes TcpListener, and accept() becomes either
AcceptSocket() or AcceptTcpClient() etc.

Cheers,
--
Joerg Jooss
jo*********@gmx.net

Thanks for the tips. Believe it or not removing the read loop and replacing
it with a single read command helped correct the problem. I still haven't
figured out why but I'll keep playing with it until it hits me.

Once the first request was working closing the socket, as you suggested,
made a huge difference in performance. I'm surprised it was not in any of
the online examples I looked at.

As far as exception handling goes - I know it is less than optimal :). I
removed any code that was not necessary for the server to run, once I
determine that exceptions were not being thrown when my code was
misbehaving, in order to make pin pointing the problem a little easier, but
don't worry, I will be sure to add plenty of exception handling once I am
happy with the basic functionality.

Thanks Again,
Dave

"Joerg Jooss" <jo*********@gmx.net> wrote in message
news:eH*************@TK2MSFTNGP10.phx.gbl...

News" <nospam> wrote:

Thanks Joerg,

Cassini looks like it will be very helpful, it is definitely a more
complete package than any of the examples I have come across to
date, but I'd still like to understand why my simple example doesn't
work as expected before getting into more complex examples. Even
though it is single threaded shouldn't the listener make itself
available again once it has finished processing a request? I'd also
like to try to understand why it is not consistently serving up the
first request.

Well, it should. After looking at your code again, there are still a
couple of issues that need to be taken care of:

1. Utter lack of exception handling ;-) This is quite dangerous anyway,
but since 99.9% of all exceptions are to be expected in the main server
thread, a simple try/catch in main() won't help.

2. Review the docs for TcpClient and NetworkStream on MSDN. For example:
"You must close the NetworkStream when you are through sending and
receiving data. Closing TcpClient does not release the NetworkStream."

Unfortunately, MSDN's own samples are sometimes wrong if this is true. I
guess not adhering to those guidelines may have weird side effects.

3. If you know Java (or better its java.net package), a multithreaded
HTTP server can be found at
http://www.devhood.com/tutorials/tut...utorial_id=396
&printer=t

ServerSocket becomes TcpListener, and accept() becomes either
AcceptSocket() or AcceptTcpClient() etc.

Cheers,
--
Joerg Jooss
jo*********@gmx.net

Dave,

There's a couple problems. First your reading until you get a zero
byte return. That will only happen when the socket is closed by the
client. The client won't close the socket because it's waiting for
your response.

You need to read until you get to the end of the HTTP request. So
read and append to a buffer. Then check the buffer end for
'\r\n\r\n'.

Second is IE is using HTTP 1.1 with keep alives. So it's going to
keep reading until either you close the socket or send the correct
HTTP 1.1 response. Frankly I'm not sure what that is - been a while
since I read the HTTP spec.

Easy thing to do is simply close the socket. Which is not happening
with your code because you've got an un-disposed network stream
that's holding the socket open.
Here's your ServiceThread function modified to do what I think your
after:

private void ServerThread()
{
int requestCounter = 0;

Byte[] buffer = new Byte[1024];
char[] charBuf = new char[1024];
StringBuilder sb = new StringBuilder(1024,4096);

while(true)
{
using( TcpClient client = _listener.AcceptTcpClient())
{
using( NetworkStream stream = client.GetStream())
{
++requestCounter;

int bytesRead;
int charsConverted;

while((bytesRead = stream.Read(buffer, 0, buffer.Length)) != 0)
{
charsConverted =
Encoding.ASCII.GetChars(buffer,0,bytesRead,charBuf ,0);

if(charsConverted > 0)
{
sb.Append(charBuf,0,charsConverted);

int currentRequestSize = sb.Length;

if(currentRequestSize > 3)
{
if('\n' == sb[currentRequestSize-1] && '\r' ==
sb[currentRequestSize-2] &&
'\n' == sb[currentRequestSize-3] && '\r' ==
sb[currentRequestSize-4])
{
// we've got our request
break;
}
}
// else we don't have a full HTTP request yet so keep reading
}
else
{
// if we don't throw here we risk missing the \r\n and hanging
for more input

throw new ApplicationException("failed to convert HTTP request
to ascii characters");
}
}

string request = "request [" + requestCounter.ToString() + "] " +
sb.ToString();

sb.Remove(0,sb.Length);

string output = "HTTP/1.1 200 OK\r\n";
output = output + "Content-type: text/plain\r\n";
output = output + "Content-length: " + request.Length + "\r\n";
output = output + "\r\n";
output = output + request;

byte[] msg = System.Text.Encoding.ASCII.GetBytes(output);

stream.Write(msg, 0, msg.Length);

} // using stream
} // using client
} // forever
} // end ServerThread

Davewrote: Thanks for the tips. Believe it or not removing the read loop and
replacing it with a single read command helped correct the problem. I still haven't figured out why but I'll keep playing with it until it hits me.

Once the first request was working closing the socket, as you suggested, made a huge difference in performance. I'm surprised it was not in any of the online examples I looked at.

As far as exception handling goes - I know it is less than optimal :). I removed any code that was not necessary for the server to run, once I determine that exceptions were not being thrown when my code was
misbehaving, in order to make pin pointing the problem a little easier, but don't worry, I will be sure to add plenty of exception handling once I am happy with the basic functionality.

Thanks Again,
Dave

"Joerg Jooss" <jo*********@gmx.net> wrote in message
news:eH*************@TK2MSFTNGP10.phx.gbl...
News" <nospam> wrote:

Thanks Joerg,

Cassini looks like it will be very helpful, it is definitely a more
complete package than any of the examples I have come across to
date, but I'd still like to understand why my simple example doesn't work as expected before getting into more complex examples. Even
though it is single threaded shouldn't the listener make itself
available again once it has finished processing a request? I'd also like to try to understand why it is not consistently serving up the
first request.

Well, it should. After looking at your code again, there are still a couple of issues that need to be taken care of:

1. Utter lack of exception handling ;-) This is quite dangerous anyway, but since 99.9% of all exceptions are to be expected in the main server thread, a simple try/catch in main() won't help.

2. Review the docs for TcpClient and NetworkStream on MSDN. For example: "You must close the NetworkStream when you are through sending and
receiving data. Closing TcpClient does not release the NetworkStream."
Unfortunately, MSDN's own samples are sometimes wrong if this is true. I guess not adhering to those guidelines may have weird side effects.

3. If you know Java (or better its java.net package), a multithreaded HTTP server can be found at
http://www.devhood.com/tutorials/tut...utorial_id=396 &printer=t

ServerSocket becomes TcpListener, and accept() becomes either
AcceptSocket() or AcceptTcpClient() etc.

Cheers,
--
Joerg Jooss
jo*********@gmx.net[/quote]

----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Thanks for the help Mike. I've found that closing the socket helped quit a
bit, obvious I should spend a little time with the http 1.1 spec. Your
explanation of the read issue also makes things a little clearer. My
solution to this point was to open a second stream for writing after the
read stream closed, which is obviously not the most efficient way to handle
this situation. I appreciate you taking the time to include a code example
as well, it has been most helpful.

Thanks Again,
Dave
"Mike Junkin" <mi********@hotmail-dot-com.no-spam.invalid> wrote in message
news:3f**********@127.0.0.1...

Dave,

There's a couple problems. First your reading until you get a zero
byte return. That will only happen when the socket is closed by the
client. The client won't close the socket because it's waiting for
your response.

You need to read until you get to the end of the HTTP request. So
read and append to a buffer. Then check the buffer end for
'\r\n\r\n'.

Second is IE is using HTTP 1.1 with keep alives. So it's going to
keep reading until either you close the socket or send the correct
HTTP 1.1 response. Frankly I'm not sure what that is - been a while
since I read the HTTP spec.

Easy thing to do is simply close the socket. Which is not happening
with your code because you've got an un-disposed network stream
that's holding the socket open.
Here's your ServiceThread function modified to do what I think your
after:

private void ServerThread()
{
int requestCounter = 0;

Byte[] buffer = new Byte[1024];
char[] charBuf = new char[1024];
StringBuilder sb = new StringBuilder(1024,4096);

while(true)
{
using( TcpClient client = _listener.AcceptTcpClient())
{
using( NetworkStream stream = client.GetStream())
{
++requestCounter;

int bytesRead;
int charsConverted;

while((bytesRead = stream.Read(buffer, 0, buffer.Length)) != 0)
{
charsConverted =
Encoding.ASCII.GetChars(buffer,0,bytesRead,charBuf ,0);

if(charsConverted > 0)
{
sb.Append(charBuf,0,charsConverted);

int currentRequestSize = sb.Length;

if(currentRequestSize > 3)
{
if('\n' == sb[currentRequestSize-1] && '\r' ==
sb[currentRequestSize-2] &&
'\n' == sb[currentRequestSize-3] && '\r' ==
sb[currentRequestSize-4])
{
// we've got our request
break;
}
}
// else we don't have a full HTTP request yet so keep reading
}
else
{
// if we don't throw here we risk missing the \r\n and hanging
for more input

throw new ApplicationException("failed to convert HTTP request
to ascii characters");
}
}

string request = "request [" + requestCounter.ToString() + "] " +
sb.ToString();

sb.Remove(0,sb.Length);

string output = "HTTP/1.1 200 OK\r\n";
output = output + "Content-type: text/plain\r\n";
output = output + "Content-length: " + request.Length + "\r\n";
output = output + "\r\n";
output = output + request;

byte[] msg = System.Text.Encoding.ASCII.GetBytes(output);

stream.Write(msg, 0, msg.Length);

} // using stream
} // using client
} // forever
} // end ServerThread

Davewrote: Thanks for the tips. Believe it or not removing the read loop and
replacing

it with a single read command helped correct the problem. I still

haven't

figured out why but I'll keep playing with it until it hits me.

Once the first request was working closing the socket, as you

suggested,

made a huge difference in performance. I'm surprised it was not in

any of

the online examples I looked at.

As far as exception handling goes - I know it is less than optimal

:). I

removed any code that was not necessary for the server to run, once

I

determine that exceptions were not being thrown when my code was
misbehaving, in order to make pin pointing the problem a little

easier, but

don't worry, I will be sure to add plenty of exception handling once

I am

happy with the basic functionality.

Thanks Again,
Dave

"Joerg Jooss" <jo*********@gmx.net> wrote in message
news:eH*************@TK2MSFTNGP10.phx.gbl...
News" <nospam> wrote:

Thanks Joerg,

Cassini looks like it will be very helpful, it is definitely a more
complete package than any of the examples I have come across to
date, but I'd still like to understand why my simple example

doesn't

work as expected before getting into more complex examples. Even
though it is single threaded shouldn't the listener make itself
available again once it has finished processing a request? I'd

also

like to try to understand why it is not consistently serving up the
first request.

Well, it should. After looking at your code again, there are still

a

couple of issues that need to be taken care of:

1. Utter lack of exception handling ;-) This is quite dangerous

anyway,

but since 99.9% of all exceptions are to be expected in the main

server

thread, a simple try/catch in main() won't help.

2. Review the docs for TcpClient and NetworkStream on MSDN. For

example:

"You must close the NetworkStream when you are through sending and
receiving data. Closing TcpClient does not release the

NetworkStream."

Unfortunately, MSDN's own samples are sometimes wrong if this is

true. I

guess not adhering to those guidelines may have weird side effects.

3. If you know Java (or better its java.net package), a

multithreaded

HTTP server can be found at

http://www.devhood.com/tutorials/tut...utorial_id=396

&printer=t

ServerSocket becomes TcpListener, and accept() becomes either
AcceptSocket() or AcceptTcpClient() etc.

Cheers,
--
Joerg Jooss
jo*********@gmx.net[/quote]

----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet

News==---- http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption

=---