Jump to content

A single-threaded HTTP server


Recommended Posts

Posted

Artigo com código fonte de um projecto em C# para o desenvolvimento de um simples WebServer com apenas uma thread.

Artigo muito fixe para quem quiser explorar o mundo das comunicações, serviços e servidores....

Introduction

This article describes a simple HTTP server named 'The .Net HTTP Daemon' or NHttpD for short that runs in a single thread and can be embedded into any kind of a thick client application. To understand this article and it's concepts you should be familiar with .Net platform, C# language and have minimal background in C language and network programming.

The source code is partially based on the work of Sam Pullara (http://www.sampullara.com/). Some ideas for Pvax.Net namespace are borrowed from: http://squirl.nightmare.com/medusa/async_sockets.html.

Disclaimer.

This application is not a real, full-fledged Web server for .Net, it's just a toy. It for sure contains bugs and is inherently insecure. You must not use it to perform mission-critical tasks like nuclear plant or city water supply management. To tell the truth, you shouldn't event host your own 3-files homepage on it. If you so, do it on your own risk.

If you need a real thing use MS IIS or XSP (http://www.mono-project.com/).

The goal of article.

I'm working on a network communication project. The software requires a kind of a Web server that is going to deliver application-specific information to the clients through HTTP (Hypertext Transfer Protocol). Although I had some background in the networking, I wanted myself to get acquainted with HTTP and overall network servers design so I started to write my own Web server. I also wanted to avoid multithreading mainly because of possible synchronization issues.

I was surprised how simple the task turned out.

HTTP protocol basics.

A Web server is an application that delivers hypermedia information (from plain text to video and applications) to it's clients using HTTP. Web servers became so widespread nowadays that you can even find one in your fridge. I'm not sure but you should check it, just in case.

There are three versions of the HTTP protocol available - 0.9, 1.0 and 1.1. Version 0.9 is outdated and I haven't heard about servers or clients supporting it.

Protocol v 1.0 uses sessions like:

The client (a Web browser) connects to the server usually using TCP port 80, the server accepts the connection;

The client requests a file or other resource by sending an HTTP request (a bunch of text) to the server:

The server parses the text, sends an HTTP response (a bunch of text that may be followed by a block of binary data) and closes the connection;

The client receives the response and closes the connection.

This scheme is simple but has a huge overhead - most of files being sent over the connection are small, hundreds of bytes. A typical Web page consists of at least one HTML file and couple of images and for each piece the client opens a new connection. This issue is addressed by HTTP 1.1 protocol that introduces keep-alive connections.

In general, the protocol v 1.1 keep-alive session looks like:

The client (a Web browser) connects to the server usually using TCP port 80, the server accepts the connection;

The client requests the data required file by file or by sending an HTTP requests:

The server parses the request and sends an HTTP response but if it can it does not close the connection;

The client receives the response and, possibly, generates a new request;

When the number of incoming connections crosses some boundary, the server starts to send a special command back to the clients asking them to close the connections;

If the client receives such a command it closes the connection. It may also close the connection under other circumstances.

The keep-alive sessions use less resources and obviously more efficient so most modern browsers use them by default.

A typical HTTP request is a block of text lines: a request line and a bunch of optional request headers. The request line consists of a method name, the resource identifier and the protocol version. HTTP 1.0 and HTTP 1.1 define a lot of methods but my NHttpD server implements only one, the GET method.

A request header line consists of the header name and the header value separated by a colon (':' character). Headers contain many useful information but again, my server uses only Keep-Alive value.

The request's end is identified by an empty line.

A typical HTTP response begins with a block of text that always contains at least one response header line arranged the same way as a request header line. After headers goes an empty line and may go a block of binary or text data. It can be an HTML file, an image, even a piece of code. In general, the client must interpret it on it's own.

The response always has a header named Content-Length that defines a size of the data block. If the server doesn't send the data back to the client it must include Content-Length header anyway and set it to 0.

I think this information is more than enough to write an HTTP server. If you are interested in details, take a look at the protocols specifications. If you are not interested in it at all, use BCL classes System.Net.HttpWebRequest and System.Net.HttpWebResponse that do all the dirty work for you.

http://www.codeproject.com/Articles/12462/A-single-threaded-HTTP-server

teckV

Posted

vejam este topico sobre comunicações sobre SOCKS... como a funcionamento dos SOCKS está abstraido da linguagem em si podem estudar o mesmo analisando programas que usem socks em qualquer linguagem

no caso apresento dois programas em código fonte e em Python... um é um servidor e o outro o cliente... é a forma mais simples de se criar uma comunicação cliente/servidor.. o python é mesmo muito bom para isto..

com o programa cliente podem analisar comunicações com outros serviços para terem o controle total a nivel dos comandos que enviam... analisem os RFS como explicado no topico para saberem que comandos determinado serviço usa

http://www.portugal-a-programar.pt/index.php?showtopic=1752

teckV

  • 3 years later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.