teknologi der kan pushe data

.NET socket server måske !?

:-)

HTTP er ikke en egnet protokol til det. Hverken ASP.NET eller andre teknologier.

Snedige folk har naturligvis eksperimenteret med en never ending respons, men
det er ikke nogen optimal løsning.

Jeg er ikke så klog i det her så jeg skal helst have skåret det ud i pap, da jeg skal anbefale et valg.

http protokol - Hvad mener du - skal ikke køre på port 80?

Hvad skal der bruges til en .NET socket server? Hvordan laver jeg et testmiljø og kan jeg gøre det på min egen windåse maskine eller skal jeg lave et nyt setup? Hvad koster det - Hvad har jeg brug for? Findes der nogle eksempler?

Jeg skal ikke selv udvikle projektet, men vil gerne have en bedre grundlæggende forståelse af hvad der sker og kunne derfor godt tænke mig et eget testmiljø.

Mange spørgsmål men nu må jeg altså vide det ;-)

HTTP protokollen er protokollen som bruges mellem en browser og en normal web server.

Browseren sender en request i et format angivet af protokollen og serveren sernder et
svar tilbage i samme format.

Default bruges port 80.

Siden kan være statisk HTML, PHP, ASP, ASP.NET, JSP, CGI script etc..

Men konceptet er altså request + respons initieret af client.

En socket server er jo bare et program som man kører. Det program kan
skrives i Java eller C# eller C eller Delphi eller et femte sprog. Det kan
derfor også køre på en hvilken som helst maskine. Eneste krav er vel at der
skal lukkes op for den port som programmet lytter på (hvis man kører
en eller anden form for firewall, men det gør de fleste forhåbentligt).

Ok så langt så godt.

Klienterne skal åbne for port xxxx lokalt?

Hvad skal der bruges for at lave en .NET socket server der kan håndtere xml og køre op mod en database? Hvad ville du selv bruge af sprog? (java formodenligt) og i fald hvordan kan jeg lave et setup/testmiljø - Og igen kan det køre på min windåse med Apache og eller windåse med Win server eller skal der installeres Tomcat? Eller skal det køre på en selvstændig maskine?

Vi taler om temmeligt mange samtidige klienter - men kun små mængder XML data

Klienterne skal kun have åbnet for udgående connections (det er der normalt
altid i hjemme firewalls - firma firewalls kan være mere rstriktive). Men
server skal have åbnet for indgående på den port som der lyttes på.

.NET socket server kræver .NET og en database hvis du skal bruge sådan en (IIS er
ikke nødvendig)

Java socket server kræver java og en database hvis du skal bruge sådan en (Tomcat er
ikke nødvendig)

En socket server er bare et almindeligt program som man starter helt
almindeligt. Det kan sagtens køre på din almindelige windows maskine
ved side af din browser og din tekst behandling. Hvis du skal have
10000 samtidige clienst på så bliver der nok noget performance issue.

Hvis vi nu tager udgangspunkt i 10.000+ klienter - Hvordan kan der så boostes performance? Flere samtidige socket servers ? Flere socket servers på samme maskine, med forskellige porte? Flere servers på forskellig ip? Flere maskiner? Hvad er et realistisk bud på antal max connections der kan håndteres per server?

Bygger man så en masterserver der uddelegerer ip/port til en socket server der har plads?

Sig til hvis jeg spørger alt for dumt :))

Der er et absolut limit på 64K socket clients per server. Hvormange
clients en socket kan trække afhænger af hvad der skal laves for
hver cleint og hvor kraftig serveren er.

Socket teknologi er ikke specielt velegnet til loadsharing løsninger.

Men en dispatcher service som redirecter til en server med mindst load
må være en mulighed.

An anden mulighed må være en passthrough server som fordeler load på
maskiner bagved.

Muligvis kan en hardware load balancer gøre sådan noget, men det ligger
lidt udenfor mit ekspertise område.

Men det kan løses. Det store problem er hvis clients skal dele data/state/whatever.

I første omgang drejer det sig kun om data der skal pushes til klienten. Mit nemme alternativ er at klienten selv pinger for nye data, men det giver mange request hvor der måske ikke er brug for det. Data ændres måske kun hvert 2. minut men skulle helst opdateres så hurtigt som muligt.

Det jeg i første omgang havde forestillet mig var at klienten ved start henter xml med timestamps, id´er og andre faste data (gøres ikke på socket serveren). Hvis socket serveren så pusher et timestamp tjekkes for om det er ændret i forhold til det klienten allerede har og i fald hentes nye oplysninger (igen udenfor socket serveren).

I og med serveren kun pusher et timestamp så ligger det overførte xml på et minimalt niveau - Har lavet en test XML fil på 141 bytes. Jeg giver den 25% oven i hatten og siger 200 bytes = 0,195 KB

0,195KB * 10.000 = 1950KB - Altså langt under 64000 KB

De 64K var et antal connections ikke 64KB data.

Afhængig af formålet var det også en mulighed at skifte fra TCP til UDP.

UDP er connections less. Og på den måde mere fleksibel. Der er ikke nogen
64K limit. Loadsharing vil også være nemmere da en hvilket som helst
af serverne kan sende en packet.

Til gengæld er den ikke reliable d.v.s. at du skal selv sørge for gensend
ved packet loss. Og den er også mere problematisk med hensyn til client
firewall.

De går desværre ikke her, da jeg skal bruge TCP.

Det ligger da heldigvis under 64000 brugere - ca halvdelen pt.

Som jeg husker rigtigt så stresser tusindvis af sockets operativ systemet en del.

Og hvis du bruger en threading model fremfor en select model så kan du også drukne
i tråde.

Så 30000 samtidige brugere til en maskine vil stille nogle krav til
system konfig og din kode.

Hvis du dispatcher og lader hver server (f.eks. blades) håndtere f.eks. 5000
så er det nok nemmere.

Men det koster selvfølgelig.

Jeg håber dog ikke at man forventer at supportere 30000 samtidige brugere
på en 2500 kr. discount PC.

hehe nej det er heldigvis ikke min afdeling jeg skal bare tjekke op på hvordan det lader sig gøre bedst. Serverne skal nok være gode nok - Men om jeg kan få tilladelse til 6 maskiner kun til det her formål er nok nærmere spørgsmålet. Så bliver det nemmere at sætte en ekstra webserver op for at tage presset fra hovedserveren og så lade klienterne pinge.

omend sidstnævnte ikke giver data ligeså hurtigt.

De 5000 var kun et eksempel.

Blever applikationen med tråde eller med select ?

Jeg kender ikke forskellen så det er svært at svare på - Hvad tænker du udfra det jeg har beskrevet?

Select ellers går performance i bund p.g.a. alt formange tråde.

(eneste undtagelse er tricks som en Java app der køres med JRockit JVM, fordi
den kan mappe mange logiske tråde til færre fysiske tråde)

Se her fatter jeg slet ikke noget. ;-)

High performance server applikationer er ikke helt nemme at lave.

For den virksomhed jeg arbejder hos, har jeg udviklet et Java server-framework, som indeholder komponenter der tager sig af de trivielle og mest komplekse problemstillinger i forhold til serverudvikling og tilbyder et højere abstraktions-niveau. Frameworket kan skalere til at håndtere mange tusinde klienter, bl.a. gennem mulighed for clustering; samtidig bygger frameworket på den select-model, som arne beskriver. Vi bruger selv frameworket i alle virksomhedens servere, så jeg ved at det virker :-)

Det er ikke umuligt, at virksomheden ville sælge en licens til frameworket, eller udvikle hele serveren, hvis du var interesseret, nikolajdu.

Jeg er absolut interesseret i og med jeg i min uvidenhed ikke kan noget som helst - Har vidst engang compilet noget java...

Du kan sende en kontakt til nikolaj@reflectoria.com - Så skal jeg forsøge at fylde huller ud.

Jeg sendte en email før nytår - har du fået den?

Lægger i et svar drenge.

ok

Svar

tak for hjælpen