asynchronous socket og thread.sleep til pause - er det dårligt ?
Hej.
Hvis man har et system med asynkrone socket som læser en masse data fra en masse forskelige klinter, med tcp/ip.
Hvis så man ønsker at pause læsehastigheden en annelse så at internetforbindelse hos klienter ikke bliver overbelastet - hvordan skal man så gøre det korrekt.
Jeg tænker at man jo bare kan lave en thread.sleep(1000) før man kalder nye BeginReceive, men jeg er lidt i tvivl om det ikke i virkeligheden er et dårligt design, som vil kunne give for mange tråde etc ?
Er der indbygget noget hastighedskontrol i sockets og tcp/ip.
Er det ok at bruge thread.sleep ? - burde man ikke have et systeme med en enkelt control tråd der skulle kalde tilbage, for at sikre at metoderne i Socket svarer tilbage med det samme.
Jeg kan ikke se at det at du pauser skulle hjælpe på brugernes net forbindelse. Data vil blive bufferet på dit system udenfor .NET (ihvertfald indtil data bliver pænt store).
Umiddelbart synes jeg at hele ideen med aynch og sleep lider meget mystisk.
Det pauser brugerens netforbindelse, det er ikke mit indtryk at der bliver cashed datamængde af betydning uden for .NET. Vi kører med buffer størrelse på ca 10.000 bytes og pauser på 200 ms til 4 sekunder. Der er ingen tvivl om at det aflaster og pauser brugerens forbindelse (øjeblikket når pausen holdes).
Spørgsmålet går mere på det med selve pausen, og Thread.sleep. Som jeg ser det kan Threed.sleep være forkert at bruge, jeg tænker om det kan opstarte uforholdsmæssigt mange tråder, eller give problemer for de klasser der kalder de asynkrone metoder i socket (at de ikke svare tilbage med det samme).
Men jeg er ikke helt sikker på det, måske er det bare ok at sleep lidt.
Det er jeg heller ikke helt sikker på at det gør, det afhænger meget af hvordan asynkrone socket virker bagvedliggende.
Det er selvfølgelig også en mulighed at det bagvedliggende system ikke kan kalde om at nye data er modtager fra andre klienter så længe en socket sleeper i modtager metoden, så vil der ikke komme flere tråde, men andre problemer måske ?
Er løsning ikke bare at få en firewall som kan håndtere det ? :-) ( måske den dyre løsning )
Men lyder som om der er penge bag, og så er det klart den bedste løsning.
Typisk er download jo billigt ... hvor meget data skal du modtage, siden du vil limit det? jeg ville nok omskrive klienten, så den ikke sender så meget data ... det er i hvert fald der det er nemmest at limit det.
Jeg ville nok overveje om det er den rigtige vej at gå ... brugeren skal vel have sendt den mængde data før eller siden.
Men det ligger fast at forbindeslen skal aflastes ved hjælp at den metode jeg omtaler. Aflastning er nødvendig for at holde upload forbindelse ledig hos klient til andre formål, da der kommer til at være en del upload.
Spm går udelukkende på det med sleep, f.eks. er det jo heller ikke i orden at lave en thread.sleep inde i en asp.net side. Og jeg tror måske noget tilsvarende gør sig gældende her.
Uden at kunne se hvad der ville gå galt, så ville jeg lave limit hos den person som rent faktisk sender data'en ud på nettet. På den måde kommer din server jo også til at modtage langsommere.
Du kan vel heller ikke vide hvor meget upload en klient har? Hvis klient selv kunne stille på det, ville det jo nemt kunne tilpasses alle ...
Jeg ville i hvert fald ikke uden videre smide sleep ind i modtager enden ... men gør det på den som afsender data.
Implementerer du både klient- og server-delen af systemet? I såfald bør det vel være afsenderen, der sørger for pauserne og ikke modtageren? Herved belaster man ikke netværket unødigt ved at sende data til en klient, der i perioder ikke lytter.
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.
