Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #30651 > unrolled thread

Wieloużytkownikowy serwer udp?

Back to article view | Back to pl.comp.programming

Contents

  Wieloużytkownikowy serwer udp? Borneq <borneq@antyspam.hidden.pl> - 2017-09-06 23:31 +0200
    Re: Wieloużytkownikowy serwer udp? Szyk Cech <szyk100@o2.pl> - 2017-09-07 01:14 +0200
    Re: Wieloużytkownikowy serwer udp? gof@somewhere.invalid (Adam Wysocki) - 2017-09-08 13:00 +0000
      Re: Wieloużytkownikowy serwer udp? gof@somewhere.invalid (Adam Wysocki) - 2017-09-08 13:01 +0000
      Re: Wieloużytkownikowy serwer udp? Roman Tyczka <noemail@because.no> - 2017-09-08 15:29 +0200
        Re: Wieloużytkownikowy serwer udp? Borneq <borneq@antyspam.hidden.pl> - 2017-09-08 18:44 +0200
        Re: Wieloużytkownikowy serwer udp? gof@somewhere.invalid (Adam Wysocki) - 2017-10-04 13:39 +0000
          Re: Wieloużytkownikowy serwer udp? Roman Tyczka <noemail@because.no> - 2017-10-04 19:56 +0200
            Re: Wieloużytkownikowy serwer udp? "PawelS cbrbob(at)wbcd(dot)pl" <fake@email.org> - 2017-10-06 19:05 +0200
            Re: Wieloużytkownikowy serwer udp? gof@somewhere.invalid (Adam Wysocki) - 2017-10-12 12:40 +0000
              Re: Wieloużytkownikowy serwer udp? Roman Tyczka <noemail@because.no> - 2017-10-12 15:58 +0200
                Re: Wieloużytkownikowy serwer udp? "M.M." <mmarszik@gmail.com> - 2017-10-12 08:05 -0700
                  Re: Wieloużytkownikowy serwer udp? Roman Tyczka <noemail@because.no> - 2017-10-12 18:40 +0200
                    Re: Wieloużytkownikowy serwer udp? "M.M." <mmarszik@gmail.com> - 2017-10-12 09:49 -0700
                      Re: Wieloużytkownikowy serwer udp? "M.M." <mmarszik@gmail.com> - 2017-10-12 09:50 -0700
                        Re: Wieloużytkownikowy serwer udp? Roman Tyczka <noemail@because.no> - 2017-10-12 19:04 +0200
                          Re: Wieloużytkownikowy serwer udp? Piotr Chamera <piotr_chamera@poczta.onet.pl> - 2017-10-12 20:06 +0200
                          Re: Wieloużytkownikowy serwer udp? "M.M." <mmarszik@gmail.com> - 2017-10-12 14:09 -0700
                          Re: Wieloużytkownikowy serwer udp? "AK" <nobody@nowhere.net> - 2017-10-14 10:02 +0200
                Re: Wieloużytkownikowy serwer udp? michal@kleczek.org - 2017-10-17 06:46 -0700

#30651 — Wieloużytkownikowy serwer udp?

Jeśli chodzi o tcp to przykładem jest serwer http. Choć może złym 
przykładem, bo jedynie tam łączy się na krótko, a nie trzyma połączenia 
cały czas.
Natomiast jak to może być w przypadku udp?
Co do zrobienia: komunikacja - serwer i klient zwykle na lokalhost.
Wersja jednoużytkownikowa działa - serwer odbiera na zadanym porcie i 
wysyła do portu, z którego łączy się klient.
Teraz chciałbym niewiele klientów, 2 może 3.
Może serwer z wątkami? Ale tam nie ma połączenia, jak to będzie 
działało? Czy dla każdego klienta osobny port? czy port jeden?
Chciałbym dla każdego klienta mieć osobną sesję, każdy ma inne dane, 
nawet jest licznik kolejnych komend wydawanych z klienta, każdy klient 
ma mieć własny licznik.

[toc] | [next] | [standalone]

#30654

> Chciałbym dla każdego klienta mieć osobną sesję, każdy ma inne dane, 

Przeczysz sam sobie. Sesja to TCP. Natomiast jeśli chodziło by Ci o 
wysłanie czegoś klientowi po jednym "pingu" do serwera, to co za problem 
odpalić wątek i na jego końcu wysłać komunikat UDP do klienta na port 
który podał w "pingu"?!?

[toc] | [prev] | [next] | [standalone]

#30666

Borneq <borneq@antyspam.hidden.pl> wrote:

> Jeśli chodzi o tcp to przykładem jest serwer http. Choć może złym 
> przykładem, bo jedynie tam łączy się na krótko, a nie trzyma połączenia 
> cały czas.

Nie zawsze. Http ma mechanizmy do utrzymywania połączenia - chunked 
encoding, keepalive.

> Natomiast jak to może być w przypadku udp?

Serwer DNS.

> Może serwer z wątkami?

Rozwiązanie wewnątrz programu to jedno, ale wątki nie są potrzebne do 
realizowania serwera obsługującego wielu użytkowników. Wszystko da się 
zrobić w jednym wątku.

-- 
[ Email: a@b a=grp b=chmurka.net ]
[ Web:   http://www.chmurka.net/ ]

[toc] | [prev] | [next] | [standalone]

#30667

Adam Wysocki <gof@somewhere.invalid> wrote:

> Nie zawsze. Http ma mechanizmy do utrzymywania połączenia - chunked 
> encoding, keepalive.

Zresztą, link: https://en.wikipedia.org/wiki/HTTP_persistent_connection

-- 
[ Email: a@b a=grp b=chmurka.net ]
[ Web:   http://www.chmurka.net/ ]

[toc] | [prev] | [next] | [standalone]

#30668

On Fri, 8 Sep 2017 13:00:09 +0000 (UTC), Adam Wysocki wrote:

>> Jeśli chodzi o tcp to przykładem jest serwer http. Choć może złym 
>> przykładem, bo jedynie tam łączy się na krótko, a nie trzyma połączenia 
>> cały czas.
> 
> Nie zawsze. Http ma mechanizmy do utrzymywania połączenia - chunked 
> encoding, keepalive.

Ale to chyba nie utrzymuje połączenia w sensie TCP tylko sesję http, a to
nie jest tożsame. 
 
-- 
pozdrawiam
Roman Tyczka

[toc] | [prev] | [next] | [standalone]

#30672

W dniu 08.09.2017 o 15:29, Roman Tyczka pisze:
> Ale to chyba nie utrzymuje połączenia w sensie TCP tylko sesję http, a to
> nie jest tożsame.

Ale w takim sensie, jakim mi chodzi to jest sesja, bo robię "sesję" udp.

[toc] | [prev] | [next] | [standalone]

#30734

Roman Tyczka <noemail@because.no> wrote:

> Ale to chyba nie utrzymuje połączenia w sensie TCP tylko sesję http, a 
> to nie jest tożsame.

Jest tożsame. Chyba że chodzi o inne rozumienie sesji, bo jest jeszcze 
sesja np. zalogowana (na serwerze, a klient trzyma session ID w cookies 
lub w zmiennej), i to już nie jest tożsame :)

-- 
[ Email: a@b a=grp b=chmurka.net ]
[ Web:   http://www.chmurka.net/ ]

[toc] | [prev] | [next] | [standalone]

#30736

On Wed, 4 Oct 2017 13:39:19 +0000 (UTC), Adam Wysocki wrote:

>> Ale to chyba nie utrzymuje połączenia w sensie TCP tylko sesję http, a 
>> to nie jest tożsame.
> 
> Jest tożsame. Chyba że chodzi o inne rozumienie sesji, bo jest jeszcze 
> sesja np. zalogowana (na serwerze, a klient trzyma session ID w cookies 
> lub w zmiennej), i to już nie jest tożsame :)

Czyli wołając reqesta do serwera http i używając w nagłówku HTTP pola
keep-alive powoduję, że serwer http utrzymuje ze mną aktywne połączenie tcp
czyli de facto otwartego socketa? I sobie to połączenie wisi, aż łaskawie
zechce mi się (klientowi http) odezwać ponownie?

-- 
pozdrawiam
Roman Tyczka

[toc] | [prev] | [next] | [standalone]

#30750

Roman Tyczka pisze:
> On Wed, 4 Oct 2017 13:39:19 +0000 (UTC), Adam Wysocki wrote:
> 
>>> Ale to chyba nie utrzymuje połączenia w sensie TCP tylko sesję http, a 
>>> to nie jest tożsame.
>> Jest tożsame. Chyba że chodzi o inne rozumienie sesji, bo jest jeszcze 
>> sesja np. zalogowana (na serwerze, a klient trzyma session ID w cookies 
>> lub w zmiennej), i to już nie jest tożsame :)
> 
> Czyli wołając reqesta do serwera http i używając w nagłówku HTTP pola
> keep-alive powoduję, że serwer http utrzymuje ze mną aktywne połączenie tcp
> czyli de facto otwartego socketa? I sobie to połączenie wisi, aż łaskawie
> zechce mi się (klientowi http) odezwać ponownie?

Prawie tak jest, z dokładnością do poniższych ustawień:

#
# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
#
#KeepAlive Off
KeepAlive On

#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
#
MaxKeepAliveRequests 100

#
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
#
KeepAliveTimeout 15

[toc] | [prev] | [next] | [standalone]

#30792

Roman Tyczka <noemail@because.no> wrote:

> Czyli wołając reqesta do serwera http i używając w nagłówku HTTP pola
> keep-alive powoduję, że serwer http utrzymuje ze mną aktywne połączenie tcp
> czyli de facto otwartego socketa? I sobie to połączenie wisi, aż łaskawie
> zechce mi się (klientowi http) odezwać ponownie?

Tak. Jak masz do wyświetlenia 15 obrazków z jednej domeny, to nie ma sensu 
tworzyć 15 połączeń. Można zrobić keepalive i pobrać wszystkie w jednym.

-- 
[ Email: a@b a=grp b=chmurka.net ]
[ Web:   http://www.chmurka.net/ ]

[toc] | [prev] | [next] | [standalone]

#30793

On Thu, 12 Oct 2017 12:40:08 +0000 (UTC), Adam Wysocki wrote:

> Roman Tyczka <noemail@because.no> wrote:
> 
>> Czyli wołając reqesta do serwera http i używając w nagłówku HTTP pola
>> keep-alive powoduję, że serwer http utrzymuje ze mną aktywne połączenie tcp
>> czyli de facto otwartego socketa? I sobie to połączenie wisi, aż łaskawie
>> zechce mi się (klientowi http) odezwać ponownie?
> 
> Tak. Jak masz do wyświetlenia 15 obrazków z jednej domeny, to nie ma sensu 
> tworzyć 15 połączeń. Można zrobić keepalive i pobrać wszystkie w jednym.

Ja nie pytam o teorię i logiczne rozwiązanie. Pytam o implementacje na
poziomie serwera HTTP, np. apache. 
Jeśli byłaby to prawda to serwery typu fejsbuk miałyby otwarte dziesiątki
milionów socketów i pożarte olbrzymie zasoby na "nie wiadomo co", bo wszak
klient może się więcej nie odezwać a socket musi wisieć, bo nie wiadomo czy
się odezwie czy nie.

-- 
pozdrawiam
Roman Tyczka

[toc] | [prev] | [next] | [standalone]

#30794

On Thursday, October 12, 2017 at 3:58:34 PM UTC+2, Roman Tyczka wrote:
> On Thu, 12 Oct 2017 12:40:08 +0000 (UTC), Adam Wysocki wrote:
> 
> > Roman Tyczka <noemail@because.no> wrote:
> > 
> >> Czyli wołając reqesta do serwera http i używając w nagłówku HTTP pola
> >> keep-alive powoduję, że serwer http utrzymuje ze mną aktywne połączenie tcp
> >> czyli de facto otwartego socketa? I sobie to połączenie wisi, aż łaskawie
> >> zechce mi się (klientowi http) odezwać ponownie?
> > 
> > Tak. Jak masz do wyświetlenia 15 obrazków z jednej domeny, to nie ma sensu 
> > tworzyć 15 połączeń. Można zrobić keepalive i pobrać wszystkie w jednym.
> 
> Ja nie pytam o teorię i logiczne rozwiązanie. Pytam o implementacje na
> poziomie serwera HTTP, np. apache. 
> Jeśli byłaby to prawda to serwery typu fejsbuk miałyby otwarte dziesiątki
> milionów socketów [...]

10mln podziel na 60tys komputerów i już nie jest tak strasznie.

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#30795

On Thu, 12 Oct 2017 08:05:28 -0700 (PDT), M.M. wrote:

>>>> Czyli wołając reqesta do serwera http i używając w nagłówku HTTP pola
>>>> keep-alive powoduję, że serwer http utrzymuje ze mną aktywne połączenie tcp
>>>> czyli de facto otwartego socketa? I sobie to połączenie wisi, aż łaskawie
>>>> zechce mi się (klientowi http) odezwać ponownie?
>>> 
>>> Tak. Jak masz do wyświetlenia 15 obrazków z jednej domeny, to nie ma sensu 
>>> tworzyć 15 połączeń. Można zrobić keepalive i pobrać wszystkie w jednym.
>> 
>> Ja nie pytam o teorię i logiczne rozwiązanie. Pytam o implementacje na
>> poziomie serwera HTTP, np. apache. 
>> Jeśli byłaby to prawda to serwery typu fejsbuk miałyby otwarte dziesiątki
>> milionów socketów [...]
> 
> 10mln podziel na 60tys komputerów i już nie jest tak strasznie.

Tak czy owak jest to niepotrzebne i ...dziwne. 
Istnieje co prawda coś takiego jak websockets, ale to zupełnie inna bajka.

Dlatego dopytuję o szczegóły implementacyjne, a nie o to co wynika z opisu
polecenia http, bo coś czuję, że jednak nie jest to tak implementowane.
Oczywiście mogę się mylić! A lubię zaliczać dysonanse poznawcze tego
rodzaju :-)

-- 
pozdrawiam
Roman Tyczka

[toc] | [prev] | [next] | [standalone]

#30796

On Thursday, October 12, 2017 at 6:40:34 PM UTC+2, Roman Tyczka wrote:
> On Thu, 12 Oct 2017 08:05:28 -0700 (PDT), M.M. wrote:
> 
> >>>> Czyli wołając reqesta do serwera http i używając w nagłówku HTTP pola
> >>>> keep-alive powoduję, że serwer http utrzymuje ze mną aktywne połączenie tcp
> >>>> czyli de facto otwartego socketa? I sobie to połączenie wisi, aż łaskawie
> >>>> zechce mi się (klientowi http) odezwać ponownie?
> >>> 
> >>> Tak. Jak masz do wyświetlenia 15 obrazków z jednej domeny, to nie ma sensu 
> >>> tworzyć 15 połączeń. Można zrobić keepalive i pobrać wszystkie w jednym.
> >> 
> >> Ja nie pytam o teorię i logiczne rozwiązanie. Pytam o implementacje na
> >> poziomie serwera HTTP, np. apache. 
> >> Jeśli byłaby to prawda to serwery typu fejsbuk miałyby otwarte dziesiątki
> >> milionów socketów [...]
> > 
> > 10mln podziel na 60tys komputerów i już nie jest tak strasznie.
> 
> Tak czy owak jest to niepotrzebne i ...dziwne. 
> Istnieje co prawda coś takiego jak websockets, ale to zupełnie inna bajka.
> 
> Dlatego dopytuję o szczegóły implementacyjne, a nie o to co wynika z opisu
> polecenia http, bo coś czuję, że jednak nie jest to tak implementowane.
> Oczywiście mogę się mylić! A lubię zaliczać dysonanse poznawcze tego
> rodzaju :-)

Jest w sieci wiele przykładów serwerów i klientów http. Jeśli Ci zależy,
możesz któryś poznać. Wpisz w google np. taką frazę "qt http server"

[toc] | [prev] | [next] | [standalone]

#30797

On Thursday, October 12, 2017 at 6:49:07 PM UTC+2, M.M. wrote:
> On Thursday, October 12, 2017 at 6:40:34 PM UTC+2, Roman Tyczka wrote:
> > On Thu, 12 Oct 2017 08:05:28 -0700 (PDT), M.M. wrote:
> > 
> > >>>> Czyli wołając reqesta do serwera http i używając w nagłówku HTTP pola
> > >>>> keep-alive powoduję, że serwer http utrzymuje ze mną aktywne połączenie tcp
> > >>>> czyli de facto otwartego socketa? I sobie to połączenie wisi, aż łaskawie
> > >>>> zechce mi się (klientowi http) odezwać ponownie?
> > >>> 
> > >>> Tak. Jak masz do wyświetlenia 15 obrazków z jednej domeny, to nie ma sensu 
> > >>> tworzyć 15 połączeń. Można zrobić keepalive i pobrać wszystkie w jednym.
> > >> 
> > >> Ja nie pytam o teorię i logiczne rozwiązanie. Pytam o implementacje na
> > >> poziomie serwera HTTP, np. apache. 
> > >> Jeśli byłaby to prawda to serwery typu fejsbuk miałyby otwarte dziesiątki
> > >> milionów socketów [...]
> > > 
> > > 10mln podziel na 60tys komputerów i już nie jest tak strasznie.
> > 
> > Tak czy owak jest to niepotrzebne i ...dziwne. 
> > Istnieje co prawda coś takiego jak websockets, ale to zupełnie inna bajka.
> > 
> > Dlatego dopytuję o szczegóły implementacyjne, a nie o to co wynika z opisu
> > polecenia http, bo coś czuję, że jednak nie jest to tak implementowane.
> > Oczywiście mogę się mylić! A lubię zaliczać dysonanse poznawcze tego
> > rodzaju :-)
> 
> Jest w sieci wiele przykładów serwerów i klientów http. Jeśli Ci zależy,
> możesz któryś poznać. Wpisz w google np. taką frazę "qt http server"

Może tam Cię coś zainteresuje:
http://doc.qt.io/qt-5/qtwebsockets-echoserver-example.html

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#30798

On Thu, 12 Oct 2017 09:50:21 -0700 (PDT), M.M. wrote:

>>> Istnieje co prawda coś takiego jak websockets, ale to zupełnie inna bajka.
>>> 
>> Jest w sieci wiele przykładów serwerów i klientów http. Jeśli Ci zależy,
>> możesz któryś poznać. Wpisz w google np. taką frazę "qt http server"
> 
> Może tam Cię coś zainteresuje:
> http://doc.qt.io/qt-5/qtwebsockets-echoserver-example.html
> 
> Pozdrawiam

Ale przecież napisałem, że nie chodzi o websockety bo to inna bajka, osobna
(nowa) technologia i do czego innego służąca.
A jeśli chodzi o źródła serwerów... jedynie serwery pokroju Apache czy IIS
są tu istotne, bo to one trzymają na swoich plecach internet, a żeby zbadać
źródła takiego Apache to ...jestem za chudy w uszach. Stąd dopytuję, może
ktoś w tym siedzi zawodowo i po prostu wie.

-- 
pozdrawiam
Roman Tyczka

[toc] | [prev] | [next] | [standalone]

#30799

W dniu 2017-10-12 o 19:04, Roman Tyczka pisze:
> On Thu, 12 Oct 2017 09:50:21 -0700 (PDT), M.M. wrote:
> 
>>>> Istnieje co prawda coś takiego jak websockets, ale to zupełnie 
>>>> inna bajka.
>>>> 
>>> Jest w sieci wiele przykładów serwerów i klientów http. Jeśli Ci 
>>> zależy, możesz któryś poznać. Wpisz w google np. taką frazę "qt 
>>> http server"
>> 
>> Może tam Cię coś zainteresuje: 
>> http://doc.qt.io/qt-5/qtwebsockets-echoserver-example.html
>> 
>> Pozdrawiam
> 
> Ale przecież napisałem, że nie chodzi o websockety bo to inna bajka, 
> osobna (nowa) technologia i do czego innego służąca. A jeśli chodzi
> o źródła serwerów... jedynie serwery pokroju Apache czy IIS są tu 
> istotne, bo to one trzymają na swoich plecach internet, a żeby zbadać
> źródła takiego Apache to ...jestem za chudy w uszach. Stąd dopytuję,
> może ktoś w tym siedzi zawodowo i po prostu wie.

Z ciekawości zerknąłem do Wikipedii
(https://en.wikipedia.org/wiki/HTTP_persistent_connection), piszą, że
dla HTTP 1.1 jest to (keepalive) zachowanie domyślne. Apache ma
domyślnie ustawiony dość krótki czas utrzymywania połączenia (15 i 5
sekund w zal. od wersji).

„HTTP 1.1
In HTTP 1.1, all connections are considered persistent unless declared
otherwise.[1] The HTTP persistent connections do not use separate
keepalive messages, they just allow multiple requests to use a single
connection. However, the default connection timeout of Apache httpd 1.3
and 2.0 is as little as 15 seconds[2][3] and just 5 seconds for Apache
httpd 2.2 and above.[4][5] The advantage of a short timeout is the
ability to deliver multiple components of a web page quickly while not
consuming resources to run multiple server processes or threads for too
long.[6]”

Bardzo popularny Nginx (popularniejszy na mocno obciążonych witrynach od
Apache, https://w3techs.com/technologies/cross/web_server/ranking) ma
ten czas domyślnie ustawiony na 75 sekund, czyli już dość długo). Można
to ustawić w konfiguracji w zależności od potrzeb za pomocą dwu opcji:

Syntax:	keepalive_requests number;
Default: keepalive_requests 100;
Context: http, server, location
This directive appeared in version 0.8.0.
Sets the maximum number of requests that can be served through one
keep-alive connection. After the maximum number of requests are made,
the connection is closed.

Syntax:	keepalive_timeout timeout [header_timeout];
Default: keepalive_timeout 75s;
Context: http, server, location
The first parameter sets a timeout during which a keep-alive client
connection will stay open on the server side. The zero value disables
keep-alive client connections. The optional second parameter sets a
value in the “Keep-Alive: timeout=time” response header field. Two
parameters may differ.

The “Keep-Alive: timeout=time” header field is recognized by Mozilla and
Konqueror. MSIE closes keep-alive connections by itself in about 60 seconds.


Dokumentacja i źródła tego serwera są dostępne na http://nginx.org/

[toc] | [prev] | [next] | [standalone]

#30800

On Thursday, October 12, 2017 at 7:04:54 PM UTC+2, Roman Tyczka wrote:
> On Thu, 12 Oct 2017 09:50:21 -0700 (PDT), M.M. wrote:
> 
> >>> Istnieje co prawda coś takiego jak websockets, ale to zupełnie inna bajka.
> >>> 
> >> Jest w sieci wiele przykładów serwerów i klientów http. Jeśli Ci zależy,
> >> możesz któryś poznać. Wpisz w google np. taką frazę "qt http server"
> > 
> > Może tam Cię coś zainteresuje:
> > http://doc.qt.io/qt-5/qtwebsockets-echoserver-example.html
> > 
> > Pozdrawiam
> 
> Ale przecież napisałem, że nie chodzi o websockety bo to inna bajka, osobna
> (nowa) technologia i do czego innego służąca.
> A jeśli chodzi o źródła serwerów... jedynie serwery pokroju Apache czy IIS
> są tu istotne, bo to one trzymają na swoich plecach internet, a żeby zbadać
> źródła takiego Apache to ...jestem za chudy w uszach. Stąd dopytuję, może
> ktoś w tym siedzi zawodowo i po prostu wie.
> 
> -- 
> pozdrawiam
> Roman Tyczka

I tak nie wiem czego nie wiesz. Robi się close(socket) jeśli
upłynął zadany czas, albo po każdej odpowiedzi. Zaimplementować to
można na kilkadziesiąt sposobów i każdy będzie dobry. Jeśli
nie odpowiesz mi dlaczego chcesz to wiedzieć i do czego potrzebujesz, to
mogę jedynie ponownie odesłać do źródeł. Możesz napisać swój
edukacyjny serwer http i będziesz miał jakąś implementację bez
czytania źródeł apache i iis. Naprawdę nie trzeba być mistrzem
świata w programowaniu, aby w kilka godzin napisać swój serwer z
konfiguracją keep-alive.



Natomiast teoretycznie można by zoptymalizować czasy, ale nie 
słyszałem aby w praktyce to się stosowało. Obojętnie jak
to w danej implementacji ktoś zoptymalizuje, to po prostu 
robi się close(socekt) gdy zaszły warunki danej strategii. 
Wracając, w przypadku http, klienta każdy może napisać, więc nie 
można liczyć na rozsądne zachowanie ze strony klienta. Wszelkie 
strategie muszą być po stronie serwera. Otwieranie za każdym razem 
połączenia kosztuje. Przetrzymywanie otwartych połączeń też kosztuje. 
Serwer w przybliżeniu wie jaki jest średni rozkład prawdopodobieństwa 
zapytań od jednego klienta, a nawet wie, jakie jest rozkład po 
konkretnym zapytaniu. Jeśli znamy rozkłady, znamy koszt 
otwierania połączenia, znamy koszt przechowywania połączenia, to
można zbudować hash-table zapewniającą sub-optymalne zachowanie:

while( is_work ) 

  request = get_request

  if new_connection then
    keep_alive = init_value 
  else 
    keep_alive += hash_table[ request ]
  end if

  response = compute( request )
  send( response )

  if current_time - time_open > keep_alive
   close(socket)
  end if

  build_strategy( hash_table , request )
end while

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#30802

Użytkownik "Roman Tyczka" <noemail@because.no> napisał:

> Ale przecież napisałem, że nie chodzi o websockety bo to inna bajka, osobna
> (nowa) technologia i do czego innego służąca.

No przeciez Ci napisali w kontekscie HTTP: keep-alive

AK 

[toc] | [prev] | [next] | [standalone]

#30810

Jak chcesz wiedziec, jak to robi Fb to:
https://github.com/facebook/proxygen

--
Michal

[toc] | [prev] | [standalone]

Back to top | Article view | pl.comp.programming

csiph-web