Dynamisk uppdatering av web-sidor.

[johano]

_Äkta_ "push" är svårt att få till i en webbläsare med "ren" html, det kräver
då någon form av aktiv komponent, t.ex. en java-applet, en activex-kontroll, flash
e.dyl.

Ett vanligt sätt att komma runt det är att (som X-IL skrev ovan) låta browsern öppna
en request (Ajax) soim sedan aldrig avslutas av servern - servern kommer skicka data
tillbaka när det finns tillgängligt, men själva requesten ligger hela tiden öppen.

Såhär brukar många webbchattar funka, liksom annan typ av uppdateringar som ska
ske på serverns "initativ".

För att underlätta byggandet rekommenderar jag starkt att använda jQuery, då är
denhär typen av kodande relativt enkelt och koden funkar i de flesta moderna browsers.

/johan

[sodjan]

OK.
Jag har sett andra exempel där man i princip öppnar en vanlig TCPIP connection
mot en server proces som registrerar IP adressen och sedan skickar data
tillbaka så länge som kanalen finns kvar och är öppen. Det finns alltså
ingen HTTP session öppen mer än initialt när sidan laddas upp. Jag
funderade på om det var något sådant som de gjorde på börssidan.

Jag har även sett att man kan göra liknande saker från ActionScript
eller Silverlight, men då bygger man in presentationen också i själva
Flash eller Silverlight objektet (som jag har förstått det, vilket inte
måste vara korrekt ).

> ...att få till i en webbläsare med "ren" html,

Hm, om det lät som att det var ett krav så ber jag om ursäkt.

[PHermansson]

Flash, Silverlight och Ajax är ju moderna tekniker som används för sånt här, så det är en beprövad lösning. Och med Ajax överför man ju bara dynamiska data, blir ju inga trafikmängder att prata om.

[sodjan]

OK.
Man Ajax är fortfarande pull/poll, inte push.
Beroende på förhållandet mellan tiden mellan ändringar
resp kravet på uppdateringsfördröjning, så blir det mer
eller mindre overhead i alla fall. Om *mängden* är ganska
ointressant. Det är *antalet* accesser som är intressant.
D.v.s att undvika "onödiga" transaktioner.

Aja, exempel med börs-sidan gav kanske inte så mycket. Jag
hoppades att det var någon som var bevandrad i tekniken och
kunde se lite snabbt hur de har gjort. Helt OK...

[Nerre]

Jag har sett andra exempel där man i princip öppnar en vanlig TCPIP connection
<klipp>
ingen HTTP session öppen mer än initialt när sidan laddas upp. Jag

Vad menar du skillnaden skulle vara mellan en "vanlig" TCP/IP-session och en http-session?

En http-session är ju i princip en "telnet" till port 80 (det går att köra telnet till port 80 på en webserver och skriva "GET /"). Det är i princip ingen skillnad mellan t.ex. http, smtp, imap eller telnet annat än vilka kommandon och svar som skickas.

[TomasL]

Så länge porten inte pollas, kommer webbserver att stänga den efter en stund.
Tanken med just HTTP är att anslutningen stängs efter det att data skickas.
Vid till exempel en normal webbsida så öppnas och stängs anslutningen för varje del av sidan som skickas.
Till exempel, Webbläsaren skicka ett GET, få all HTML-kod, stänger anslutningen, alternativt stänger servern anslutningen, beroende på hur time-outen är satt och serverns last.
Webbläsaren tolkar sidan och skickar sedan ett nytt get för varje enskilt element, med en ny anslutning per element. (kan vara bilder o dyligt)

[jbulow]

Ang. att göra javascript läsbar så verkar första träffen på google användbar: http://jsbeautifier.org/

[TomasL]

jbulow, den var riktigt imponerande, fixade alla 166k teken i koden som länkades innan på några sekunder.

[jbulow]

Kanske har slarvläst tråden men jag såg inte att jQuery nämnt än. jQuery är ett javascript-bibliotek som abstraherar bort browser-specifika implementationsdetaljer samt erbjder en mängd användabara funktioner och abstraktioner. Bl.a erbjuder jQuery ett AJAX-API som är bra: http://api.jquery.com/jQuery.ajax/ , http://www.w3schools.com/jquery/jquery_ajax.asp .

Nu vet jag inte vad du har för krav på server-sidan, men de vanliga valen är apache eller lighttpd, eventuellt nginx. Någon av dessa servrar med php-backend kan ju skapa en hyffsat enkel applikationsstack.

Skulle du finna javascript ok som språk finns även node.js som server-alternativ. I node.js utvecklar du även server-sidan i javascript. node.js är väldigt effektiv då den kör på googles v8 javascript implementation (samma som google chrome använder).

[sodjan]

> Vad menar du skillnaden skulle vara mellan en "vanlig" TCP/IP-session och en http-session?

Sorry, lite oklar där... Det öppnas alltså en kanal på en helt annan port (än 80) mellan
scriptet i browsern och en speciell server process (som inte har något med web-serven
att göra). Så resten av trafiken går inte alls via web-servern som sådan. Sedan är det
serverprocessen som skickar data när det behövs. Ingen pollning från klienten.
Men det är klart att ur ren TCPIP trafik/paket synpunkt så är det samma sak.

> Nu vet jag inte vad du har för krav på server-sidan,

Det är OpenVMS och web-servern är WASD. Applikationsspråk C eller COBOL (samt Python).
http://h71000.www7.hp.com/, http://wasd.vsm.com.au/
Vill helst slippa Java och JavaScript på servern. PHP finns att installera men finns inga planer
idag. Apache finns och tillgängligt för denna plattform men det är betydligt långsammare
och drar mer resurser än WASD (som är skriven från grunden för OpenVMS) för samma jobb.

Aja, min plattform kan jag...
Det som jag igentligen undrade, som sagt, var hur börs-sidan fungerade...

[hubben]

Att öppna en anslutning som man aldrig stänger är en riktigt ful lösning som inte skalar särskilt väl. De flesta HTTP servrar har ett rätt lågt antal max-anslutningar då tanken med HTML som sagt är att anslutningarna ska ske i korta sessioner som avslutas titt som tätt. Att man sedan kan köra persistent anslutningar så att servern håller kvar anslutningen mot klienten tills nästa anrop kommer är
ett sätt att få bättre prestanda, men där kan anslutningen stängas och nyttjas av en annan klient när så behövs.

I "tidernas begynnelse" använde jag den tekniken för några lösningar, men fick ofta problem med minnesläckor som krävde onödigt mycket resurser på servern då varken server eller scriptingspråk egentligen var byggda för denna typ av program.

Ska du köra någon sorts "push" metod så kräver det att servern kan öppna en anslutning mot klienten. Det kanske fungerar bra om du har full koll på hela nätet från server till klient, men i vanliga fall finns det brandväggar och NAT:ningar som ställer till det.

Nu vet jag inte hur överbelastat ert nät är, men ett slänga iväg ett AJAX-anrop i sekunden och få ett <nodata /> som svar kräver inte särskilt mycket av vare sig nät, klient eller server.
Men om någon vet en pushmetod där klienten kan vara passiv - som fungerar bra - så är jag idel öra.

[labmaster]

Om du inte vill använda poll-teknik från klientsidan måste du bygga en programvara i klienten som lyssnar på en viss port samtidigt som den presenterar sin närvaro för servern. Enklast är att bygga en SOAP-service till klientsidan eftersom det ofta finns stöd för detta i olika server-programvarar. PHP-har exempelvis detta stöd.

Jag hade troligen byggt klienten i Java eftersom den då blir hyfsat portabel mellan olika operativsystem.

[Muppis]

Är det verkligen ett problem att 20 klienter gör ett anrop i sekunden? Är det en uråldrig server du har fått tag på?

Det var längesen jag stötte på en servrer som inte brukar klara 500r/s med Apache HTTPD och PHP. PHP är ju ett ful-språk av rang dessutom.

Ett halv-vettigt CGI-script i C borde klara iaf 1000 r/s på även en halvgammal server. Om du använder en relationsdatabas kanske du får lite lägre prestanda, men det är inget som inte går att lösa med lite cachning.