flat assembler
Message board for the users of flat assembler.
Index
> Projects and Ideas > Another FreshLib based project - phWeb server. Goto page 1, 2, 3 Next |
Author |
|
JohnFound 15 Aug 2012, 08:20
"phWeb" means "photon web" and is aimed to be very fast and very light web server with CGI support.
It is loosely based on AWeb server, ported to FASM from XVilka, but these sources was used only as a guide, because the original sources has very low quality code - for example using strlen to count the length of the string constants, wide use of global variables and very obfuscated stack farmes, based on direct offsets. Anyway, now it is based on FreshLib and has very clean, simple and readable code. ( ) The source repository is: here. I will attach the current source for those who don't want to use fossil. The server is not fully functional now. It works with static files only and has some problems with the protocols. For example, Dillo browser does not display images and sometimes the server does not return the page (especially on heavy loads). The configuration is saved in uConfig database. A simple editor for this files (Win32 and Linux) is located in "/cfgEditor". [EDIT]I removed the attached file because it was outdated. Please use the repository link above.[/EDIT] _________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 Last edited by JohnFound on 02 Dec 2015, 13:39; edited 1 time in total |
|||
15 Aug 2012, 08:20 |
|
JohnFound 15 Aug 2012, 11:00
XVilka wrote: Nice work, but please, dont waste your time implementing CGI, try SCGI (Simple CGI) or FCGI (FastCGI) - they are fit better to be tiny&fast as assembler did, and modern protocols too. Well, I still didn't make any work on server side scripting. Maybe both CGI and SCGI will make good enough set of features. I have to read the specifications first and then to decide what to do. For now it is only a test ground for the FreshLib socket functions. But the project is open, so anyone can join and help in the development. Who knows, maybe it will become the fastest web server in the world one day. _________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 |
|||
15 Aug 2012, 11:00 |
|
XVilka 15 Aug 2012, 12:32
full SCGI specification - just one page of text, see that http://python.ca/scgi/protocol.txt
|
|||
15 Aug 2012, 12:32 |
|
JohnFound 15 Aug 2012, 14:01
XVilka wrote: full SCGI specification - just one page of text, see that http://python.ca/scgi/protocol.txt It seems to be simple, but this document does not explain some important things. For example, the SCGI script seems to run all the time and acts like a server. So, on which address and which port this server has to be bound? Who will start and stop the scripts and when? What if I have multiply scripts? All they have to run all the time, waiting for connection or will be run/stop by the web server using some strategy? How the script will know the assigned port to listen for requests? Of course every of these questions have some (not so complex) answer, but still, the implementation needs some effort. _________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 |
|||
15 Aug 2012, 14:01 |
|
XVilka 15 Aug 2012, 16:30
There is not standard for that - you can run multiple SCGI applications on multiple ports and hosts, while web server can talk with any of them (choosing by some case at config). Who start them - user e.g. Same idea, as for FastCGI, e.g. with php-fpm server, or wsgi with python applications, etc
|
|||
15 Aug 2012, 16:30 |
|
JohnFound 15 Aug 2012, 16:42
IMHO, it is really stupid to run all you scripts at once to wait for someone who could (not) ask for them. The case with PHP or other interpreter is totally different, because they run all .php scripts of the web server. The user only changes the .php files and they are the CGI scripts actually. In this case the PHP interpreter is some kind of server extension.
So, FastCGI and SCGI are rather plugins interface, than CGI scripts interface. |
|||
15 Aug 2012, 16:42 |
|
JohnFound 16 Aug 2012, 22:16
I have the following issue with phWeb server. The main loop of the server looks like this:
Code: stdcall SocketListen, [.hSocket], [maxConnections] jc .listenerr ; Accept connection .doAccept: stdcall SocketAccept, [.hSocket], 0 jc .accepterr stdcall ThreadCreate, ConnectionHandler, eax ; stdcall ConnectionHandler, eax jmp .doAccept You can see that the procedure ConnectionHandler can be used as a regular procedure and as a thread procedure. This procedure accepts one argument - the socket handle returned by "SocketAccept" procedure. It process the data sent to this socket, returns the answer and then closes the socket passed. Everything works fine, but when I use it in multi-thread mode, the Windows Task Manager displays the total handles number, raising all the time. For example, if I made 100000 requests to the server, then the number of handles raises by 100000 as well. It looks like the allocated sockets are never closed, but they actually are. The winsock procedure "closesocket" returns no error. All these allocated sockets are freed when I close the program. This behavior is the same even when I make only one connection at time - i.e. there is only one thread. (well, two actually - the main thread and the ConnectionHandler one) On the other hand, when I use ConnectionHandler procedure as a procedure, the handles number in the Task manager does not raise. The drawback of this mode is that it can handle only one connection at time. Any ideas? _________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 |
|||
16 Aug 2012, 22:16 |
|
LocoDelAssembly 16 Aug 2012, 22:47
Maybe it is the thread handles that are not closed?
|
|||
16 Aug 2012, 22:47 |
|
JohnFound 16 Aug 2012, 22:55
LocoDelAssembly wrote: Maybe it is the thread handles that are not closed? Yes, this seems to be the answer. I totally forgot about these handles... _________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 |
|||
16 Aug 2012, 22:55 |
|
Enko 17 Aug 2012, 14:07
What about using QueueUserWorkItem() in windows insted of CreateThread?
The diference is that with QueueUserWorkItem() you just use RET and windows terminate the thread. |
|||
17 Aug 2012, 14:07 |
|
JohnFound 17 Aug 2012, 16:19
Enko wrote: What about using QueueUserWorkItem() in windows insted of CreateThread? Well, it is the same for the normal threads as well. Usual threads are better, because the API is almost equal among all OSes. Anyway, today I tried to make some benchmarks: - the server was set on netbook eeepc with 1.6GHz INTEL ATOM. - The client was my office computer - Intel dual code something CPU - The benchmark software - "ab.exe" - apache bench for windows. - 100Mbs direct network connection. In this setup, the server easy handles 3000..4000 concurrent connections, created by 4 instances of apache bench running 1000 connections. This means of course 3000..4000 threads running simultaneously. It was possible to load it even more, but the client computer refused to run more than 4 instances of ab.exe _________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 |
|||
17 Aug 2012, 16:19 |
|
edfed 17 Aug 2012, 21:18
maybe we can join to test the connection limits.
what is the procedure to run apache bench in order to overload your server? |
|||
17 Aug 2012, 21:18 |
|
Enko 17 Aug 2012, 21:27
edfed wrote: maybe we can join to test the connection limits. If it is posible to coordinate the time with you, I could help testing to. But, the only linux i have is puppy linux on usb drive. |
|||
17 Aug 2012, 21:27 |
|
edfed 17 Aug 2012, 21:44
i think a procedure would be to let run permanentlly an instance of the server, and let testers connect as many as they can when they can.
and at the of a week of tests, john will have enough logs about what happened to improve the server. |
|||
17 Aug 2012, 21:44 |
|
sleepsleep 17 Aug 2012, 22:11
rename ab.exe to cd.exe?
btw, great project john, i want to use it tooo!! |
|||
17 Aug 2012, 22:11 |
|
JohnFound 17 Aug 2012, 22:31
The remote test is IMHO not possible, because of limited internet connection of my home network. The bandwidth will end before the server get loaded enough.
I have to fix some Linux issues (it hangs now after 382 connections) and then will try to set it on public computer for community tests. |
|||
17 Aug 2012, 22:31 |
|
r22 20 Aug 2012, 14:56
Do proper request sanitation before you host the server publicly
- Request handling thread should time out the request after (a) using too much memory from giant upload (b) connection is hung open with no data - Basic maximum size checks for request parts (a) URL entity is larger than 2048 path and 4096 query (b) HTTP headers are larger than ~8k-16k - URL file path checks to make sure it's inside the root directory .. / .. / .. / bad The time-out checks would likely need a lot of refactoring using the async socket select api and may be out of scope for what you're trying to accomplish. Perhaps adding another thread that monitors how long a request processing thread has been alive and killing it if it's been active too long would be sufficient. Maybe having every request processing thread have a little structure of memory that has its current state e.x. WAITING_FOR_REQUEST, PARSING_REQUEST, SEND_RESPONSE with timestamps. I want server side HTML with FASM code inside. "index.fasm" Code: <html> <head><title>Time</title></head> <body> <strong><% RDTSC cinvoke FASMWebFramework_Print, <'%d',0>, EAX %></strong> </body> </html> |
|||
20 Aug 2012, 14:56 |
|
uor99 07 Jan 2015, 00:11
fastcgi wanted !
|
|||
07 Jan 2015, 00:11 |
|
JohnFound 07 Jan 2015, 07:21
uor99 wrote: fastcgi wanted ! Unfortunately, I simply don't have time to work on this project. It misses even simple CGI. If you want to help, you are welcome. _________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 |
|||
07 Jan 2015, 07:21 |
|
Goto page 1, 2, 3 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.