Przenosiny strony

9 kwietnia 2012 r.

  • Z przyczyn technicznych strona HttpInD zmienia adres.
  • Nadal walczę z obsługą protokołu HTTPS.
  • Trwa to tak długo z powodu ostatnio bardzo ograniczonych moich możliwości czasowych.

Diaboli HttpInD Server 0.3.2

27 marca 2011 r.

  • Wersja "telnet ready"
  • Rezygnacja z metody POST (na razie i tak brak obsługi skryptów)
  • Poprawiony mechanizm analizy zapytań klientów
  • Poprawiony mechanizm Content-Range


Pobierz:

Diaboli HttpInD Server 0.3.1

25 marca 2011 r.

Bardziej stabilna wersja. Kod źródłowy został uporządkowany. Teraz zmienne nie są już inicjowane na poziomie fibera lecz na poziomie wątku. Pozwoliło to na wyeliminowanie błędów "Segmentation fault". Zmieniony został też scenariusz obsługi połączeń. Teraz każde nowe połączenie kierowane jest do pierwszego wolnego fibera w wątku o najmnieszej ilości wykorzystywanych fiberów.

Pobierz:

Diaboli HttpInD Server 0.3

19 lutego 2011 r.

Nareszcie serwer HTTP a nie tylko serwer!

Obsługuje metody GET, HEAD, OPTIONS i częściowo POST.


Obsługiwane nagłówki klienta:

  • Accept
  • Accept-Charset
  • If-Modified-Since
  • Range

Nagłówki wysyłane przez serwer:
  • Allow
  • Accept-Ranges
  • Connection
  • Content-Length
  • Content-Range
  • Content-Type
  • Date
  • Last-Modified
  • Server


Pobierz:

Diaboli HttpInD Server 0.2.2

15 lutego 2011 r.

Bardziej stabilna wersja.

Wykryte problemy podczas pracy pod Windows od wersji 0.2. Z braku czasu tymczasowo porzucam implementacje dla tej platformy. W podstawowych założeniach jest mowa o pracy w systemie Linux.

Pobierz:

Diaboli HttpInD Server 0.2.1

14 lutego 2011 r.

Rozwinięcie pojęcia multiplexingu znanego z wersji 0.2.

Zmiany w stosunku do poprzedniej wersji:

  • możliwość przesyłania dużych treści w częściach;
W pliku konfiguracyjnym możemy ustalić wartość byteslimitatonce. Wartość ustawiona na 0 nic nie zmienia. Gdy jest większa niż 0, wysyłany do klienta content jest dzielony na fragmenty po byteslimitatonce bajtów i ewentualnie ostatni mniejszy fragment. Każdy z fragmentów jest wysyłany za pomocą tego samego gniazda, w kolejnych wywołaniach tego samego fibera. Pomiędzy wysłaniem kolejnych fragmentów następuje przerwa w trakcie której dany fiber zostaje wstrzymany, następuje przejście do kolejnego fibera (o ile taki istnieje) zainicjowanego w tym samym wątku. Po obsłużeniu wszystkich innych fiberów w danym wątku (zakończenie lub również wstrzymanie), następuje powrót do tego samego fibera i wykonywanie go od miejsca w którym nastąpiło wstrzymanie jego wykonywania. Ustawienie ma sens przy wartości maxfiberperthread_count minimum 2. Możliwość ta pozwala nie dopuścić do tzw. efektu zagłodzenia w momencie gdy jeden z fiberów jest zajęty przesyłaniem do klienta ogromnego pliku, a w kolejce tego samego wątku znajdują się połączenia od innych klientów chcących pobrać dużo mniejszą ilość danych.

Pobierz:

Diaboli HttpInD Server 0.2

14 lutego 2011 r.

Do tej wersji dążyłem tak naprawdę od ponad 4 tygodni.

Zmiany w stosunku do poprzedniej wersji:

  • tzw. multiplexing połączeń sieciowych poprzez użycie fiberów;
  • wartość "backlog" została ustawiona w realnych granicach;
Multiplexing połączeń sieciowych jest uzyskiwany poprzez akceptację połączenia i przekazanie w ten sposób utworzonego gniazda z procesu do wątku, następnie z wątku do fibera. W ten sposób 1 wątek może przyjąć do obsługi wiele gniazd jednocześnie (tyle ile posiada fiberów). W danym momencie wątek może wywołać i wykonywać tylko 1 fiber, zatem wątek przyjmując do obsługi kolejne gniazda ustawia je sobie tak naprawdę w kolejce i obsługuje po kolei. W ten sposób liczba połączeń oczekujących (jeszcze nie zaakceptowanych - tzw. backlog) jest mniejsza i dlatego w sytuacjach krytycznych nowe połączenia klientów będą odrzucane rzadziej niż w standardowym rozwiązaniu. Liczba połączeń backlog jest ograniczona do wartości SOMAXCONN. SOMAXCONN jest stałą która w systemach unixowych domyślnie jest równa 128 i można zmienić jej wartość poprzez modyfikację pliku /proc/sys/net/core/somaxconn. Ustawiłem wartość backlog = 200, która automatycznie zostanie obcięta do maksymalnej wartości obsługiwanej przez system operacyjny.

Pobierz:

Diaboli HttpInD Server 0.1.1

8 lutego 2011 r.

Bardziej stabilna wersja na razie bez większych innowacji.

W porównaniu do poprzedniej wersji zmieniło się jedno:

  • utrzymywana jest zmienna ilość wątków;
Podczas tej nierównej walki zwanej tworzeniem oprogramowania, metodą prób i błędów dowiedziałem się że aby móc utworzyć nowy wątek zakotwiczony (zaalokowany) w obiekcie o tej samej nazwie, i o tej samej właściwości name co poprzedni wątek, nie wystarczy użyć funkcji thread_detachThis() pod koniec przebiegu wątku. Oprócz tego, później w przebiegu głównego wątku (procesu) należy użyć funkcji join() i dopiero wtedy można z pełnym sukcesem tworzyć drugi wątek o tych samych właściwościach. Poza tym wychodzi na to że nie jest dobrze gdy wątek wysyła komunikaty na konsolę, gdyż w przypadku intensywnej pracy wielu wątków prędzej czy później otrzymamy błąd "tango.core.Exception.IOException: :: Bad address".

Pobierz:

Diaboli HttpInD Server 0.1

23 listopada 2010 r.

Nareszcie pierwsza wersja!

Główne cechy (jak na razie ograniczenia) to:

  • obsługa metody GET;
  • obsługa jedynie plików tekstowych oraz html;
  • obsługa wielu połączeń sieciowych za pomocą wątków;
  • cały czas utrzymywana jest stała liczba wątków;
Pobierz:

Pomysł na serwer HTTP

10 października 2010 r.

Witaj na moim blogu!

Jesteś świadkiem narodzin nowego innowacyjnego serwera HTTP. Pierwsza jego stabilna wersja ma powstać w 6 miesięcy od teraz. W tym momencie jedyne co istnieje to nazwa serwera i określona wizja, która w miarę upływu czasu będzie urzeczywistniana. Naturalnie jej założenia mogą się w pewnym zakresie zmieniać.

Główne założenia implementacji to:

  • źródło napisane w języku D 1.0 z wykorzystaniem biblioteki Tango;
  • system linux jako platforma;
  • obsługiwane metody protokołu HTTP 1.1: GET, HEAD, POST, OPTIONS (lista obsługiwanych nagłówków HTTP nie jest jeszcze określona);
  • obsługa jednocześnie wielu połączeń sieciowych za pomocą threads & fibers;
  • obsługiwana metoda autoryzacji DIGGEST;
  • obsługa protokołu HTTPS przez wykorzystanie biblioteki OpenSSL;
W miarę postępu prac będą udostępniane kolejne niestabilne wersje implementacji.