Jeg har brug for at lave egen webserver i C#, vha sockets, som kan modtage filer uploaded fra html-sider.
Når jeg har modtaget og læst requestet har jeg en lang byte array, som indeholder hele httprequestet.
Den er selvfølgelig lettere avanceret at forstå og hive filer m.m. ud af.
Findes der ikke nogen klasser som kan hjælpe med til at decifrere httpreqeust.
(jeg kan ikke bruge httplisterner, det skal være med sockets, men jeg kunne godt tænke mig at finde ud af f.eks. hvordan httplisterner løser problemet).
Jeg håber at der er nogen kloge drenge der kan hjælpe mig.
Så det super nemt ud at gøre med Write til den .... og så bare smide lidt i bufferen hele tiden.
Hvordan gør i nu? Og løsningen med at drosle folk ned i hastighed, er aldrig en god løsning i min verden, da de jo så bare blive ved med at være tilsluttet ... men måske jeg har overset noget.
Tak for svar, vi skal kunne styre hastigheden godt både for at skåne server og for ikke at spise hele kraften på klienterne, da de skal kommunikere i andre sockets samtidig.
Hov, jeg tror altså ikke det hjælper noget med HttpListener.GetContext(). fordi den blocker vel bare til det hele er modtaget.
HttpListener.GetContext(): "This method blocks while waiting for an incoming request. If you want incoming requests to be processed asynchronously (on separate threads) so that your application does not block, use the BeginGetContext method."
Jeg synes nu stadig det ser ud somom at men httplistener henter man det hele på en gang, og kan ikke styre noget.
blokker indtil der kommer et request. Der er ikke noget som forhindrer dig i at starte en tråd med det samme til at processe requesten og gå tilbage og lytte med det samme.
Jeg tester det om nogen mdr og vender tilbage, skal også se lidt på andre muligheder med httplistener, fordi jeg skal også kunne køre https og det bliver nok en lidt stor mundfuld at kode selv med sockets:).
Har dog allerede kigget en del på forskellige muligheder, og min mavefornemmelse siger mig at man ikke får angang til den bagved liggende socket stream med den der context.inputStream, men blot til en stream lokalt på computeren. (det er vel også det der lidt står i dokumentationen, men who know måske er der alligevel noget at arbejde med).
Den lokale stream er jo reelt også den remote stream om man vil.
Så kan ikke lige følge dig. Du bliver nok nød til at teste noget af det i stedet for at gætte dig frem.
Du kan jo ikke styre hastigheden lokalt for hvor hurtigt clienten sender til dig ... det er klienten som bestemmer det. Men hvad du kan styre er upload til klienten, da det her er dig der bestemmer hastigheden. Selvfølgelig kan der være limitations på linjen, som så automatisk gør at der ikke kan sendes hurtige.
Der findes måder at limit hastighed på, men hvis du har læst om det på nettet, så er der ingen perfekte løsninger mht download fra en klient.
He he, godt at afprøve tingene, men det er nu ikke rigtigt det du skriver. Med sockets er der serveren der styrer tingene, klienten (broseren) sender ikke hvis server holder op med at modtage (ellers ville tingene jo også gå tabt eller skulle hobbes op ude på internettet).
Og mht til at tingene hobbes op ... der har vi TCP som sørger for at sende igen ... alt efter om den har modtager en ACK/NACK pakke tilbage eller der går rod i det, pga dårlig forbindelse. Der også også packet size og mange andre ting der holder styr på det.
Jeg tror du blander tcp/ip protokol og sockets lidt sammen her (de pakker du omtaler ligger på tcp/ip nivaue tror jeg).
Med socket siger man ligesom beginreceive, og at den skal modtage f.eks. 8192 bytes, og så kan clienten selvfølgelig frit sende, men klienten sender ikke mere end de 8192 bytes - det gør den først når man laver en nye beginreceive. Det går ikke langsomt, mindste ligeså hurtigt som almindelig web-server.
Vi er på udkig efter andre løsninger af forskellige årsager, bla pga behov for SSL.
Sockets har en buffer som den tager fra når du kalder BeginReceive eller bare Receive og så hvor meget du vil modtage.
Hvordan vil du ellers forklare at den har en Available som angiver hvor mange bytes der er i bufferen uden at man har lavet et kald til BeginReceive/Receive ... Async/Sync kald.
Men i hvert fald, en af os bliver klogere og jeg håber der kommer nogen andre på banen som bakker en af vores teorier op.
Hey, det er muligt at der er en buffer på en eller anden måde (men det er i så fald ikke en som bliver fyldt uhæmmet op). Fordi jeg har jo allerede lavet det, og det fungerer helt perfekt, jeg kan styre alt med hastigheden og holde pause f.eks. hvert 3. sek.
I chrome kan man se f.eks. se procents uploades stoppe op og starte igen.
Jeg ved det hele kan løses til perfektion med sockets, jeg er igang med at undersøge hvilke andre muligheder der er .
Ja, og det er netop pga TCP/IP og at bufferen i Sockets ikke bliver fyldt mere og at tingene bliver sendt igen. Ergo spilder du en masse båndbredde både hos dig selv og din klient. Tror mig, jeg har læst side op og ned omkring det ...
Nej, det kan ikke løses til perfektion ... det kan løses, men du spilder også båndbredde ved at gøre det, men mindre du kan styre sockets i begge ender.
Hvis du har læst om bandwidth limitation per ip, subnet, dst ip/dst net ovs ... så vil du vide det ikke sådan lige er til ... uden kunstigt at gå ind og rode ... og derved spilde båndbredde :-)
Download fra din server er 100% under din kontrol, og den kan styres uden tab ...
nu kan jeg se hvad du mener - det er en nye tanke for mig, men det afhænjer nok af hvor store klumper man sætter socket til at modtage af gangen kan jeg forestille mig - det er nu ikke mit indtryk at det er et kæmpe problem.
Spørgsmålet er så om det giver 25% eller 2% overforbrug at man holder pause ?
Ja ... man skal i hvert fald bare være klar over det. Men jeg ville vende den op ... der bliver som sådan jo nok ikke brugt mindre bånddredde fordi man begrænser brugeren ... han bliver bare ved med at upload/download i længere tid.
Det er bla. fordi applicakatinen har behov for en masse anden kommunikation med server samtidig, som ellers kan blive blokkeret eller langsom. Men nok om det, det virker fint med sockets, og jeg er ved at undersøge andre muligheder.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
