teckV Posted August 10, 2006 at 04:48 PM Report #43634 Posted August 10, 2006 at 04:48 PM 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.... IntroductionThis 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
skin Posted August 12, 2006 at 09:27 AM Report #43892 Posted August 12, 2006 at 09:27 AM Ele pede-me o login 😄 ninguem me manda isso? Our lives begin to end the day we become silent about things that matter - Martin Luther King
karva Posted August 12, 2006 at 12:31 PM Report #43922 Posted August 12, 2006 at 12:31 PM http://www.yousendit.com/transfer.php?action=download&ufid=547CD83E09F4C284 Proud LEIC-A@IST student!
skin Posted August 12, 2006 at 12:37 PM Report #43923 Posted August 12, 2006 at 12:37 PM Obrigado Karva Our lives begin to end the day we become silent about things that matter - Martin Luther King
teckV Posted August 18, 2006 at 11:30 AM Author Report #44983 Posted August 18, 2006 at 11:30 AM 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
mrpostiga Posted March 8, 2010 at 02:43 PM Report #315132 Posted March 8, 2010 at 02:43 PM http://www.yousendit.com/transfer.php?action=download&ufid=547CD83E09F4C284 file not found 👍
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now