mboost-dp1

Feedback på nyt projekt..


Gå til bund
Gravatar #1 - reefermadness  
6. mar. 2011 10:33
Hej alle newz'ere

tænkte på om jeg ikke kunne få lidt feedback på mit nye projekt:

http://gameinvite.net

Konceptet er forholdsvist simpelt:

Mange alternative IM klienter har ikke spil indbygget ligesom f.eks windows live, dette synes jeg er ærgeligt, da jeg tit benytter mig af disse sammen med min familie (Da vi pt. er spredt over hele landet), men flere og flere personer går væk fra windows live (Og med god grund, da webcam delen sutter, flash reklamer der æder 100% cpu tid, ukrypteret overførsel af beskeder osv.)


Derfor har jeg lavet en lille side hvor man kan vælge et spil, copy paste et link og spille, uden for mange dikkedarer (Som popups, påtrængende reklamer, registrering mv.)

En anden grund til at jeg har lavet siden, er at øve mig lidt i at lave flashspil, da det er noget jeg ikke har rørt i mange år..

jeg er ikke den store design guru, derfor ville det være rart at få lidt konstruktiv kritik på designet, samt lidt feedback på de enkelte spil.

Jeg vil så vidt muligt tilføje et spil hver/hver anden uge.

Ps. idéer til nye spil er også kærkommen :-)

Tak på forhånd.
Gravatar #2 - fjols
6. mar. 2011 10:44
Super simpel og indbydende design.
Rigtig simpelt at gå til. Det kunne ikke være bedre.
Jeg sidder pt. på en internet linie hvor alt undtagen web er spærret og jeg kan derfor ikke forbinde til serveren og spille.
Er det muligt at fikse? Ellers kan jeg desværre ikke bidrage med mere.
Gravatar #3 - reefermadness  
6. mar. 2011 10:47
#2 - Ja det kan godt fikses (Ved at sætte serverne op til at køre på port 80 istedet for 8020 - 8030)

Men det kræver at jeg får fat i flere IP-adresser / servere, hvilket budgettet ikke lige er til pt. (pt. kører det hele fra et enkelt VPS.net node)

Men det er noget jeg helt klart overvejer.

PS. Nogle der ved om der er andre porte som typisk er åbne på skoler / business netværk ?
Gravatar #4 - fjols
6. mar. 2011 10:56
På min gamle skole var 8080 og 1080 åbne.
Hvis du kender et program der kan tjekke det for mig så kan jeg prøve det her på Skejby sygehus.
Gravatar #5 - MiniatureZeus
6. mar. 2011 11:28
Første tanke:
MSPaint.exe FTW!! :P
Andre tanker:
Dejligt overskueligt design der er nemt at gå til og finde ud af. Har nok også noget at gøre med de simple spil og der kun er tre.

spillene virker også ret simple, hvilket dog er positivt

edit: Der mangler ligesom noget chat mellem spillerne, hvis det skal tage kampen op mod win live..
Gravatar #6 - reefermadness  
6. mar. 2011 11:33
#5 - Mspaint ? er det designet eller spillene du tænker på :-) ?

Jeg har overvejet en chat funktion (Måske enda en voicechat funktion, hvis jeg finder et eksempel på at reducere ekko i red5)

Kender du eventuelt et simpelt PHP+JS baseret poll chat script?

Eller skulle jeg lave det som en integreret del af spillet?
Gravatar #7 - MiniatureZeus
6. mar. 2011 11:40
reefermadness (6) skrev:
Mspaint ? er det designet eller spillene du tænker på :-) ?

Designet i topbaren. Er dog positivt ment!

reefermadness (6) skrev:
Eller skulle jeg lave det som en integreret del af spillet?

Kender ikke nogle scripts eller andet.
Synes det ville være smartest hvis det var en stand-alone ved siden af spillet, evt. hvis du kan gøre sådan at chatten gemmes "centralt", så det er lige meget hvilket spil du spiller, så er chat historikken der stadig.
Gravatar #8 - Colapusheren
6. mar. 2011 11:47
Apropos chat system, så kunne der jo i samme stil tilføjes et chatrum, hvor man kan lede efter modstandere. På den måde behøver man ikke have fundet en modstander via en anden IM før man benytter din side.
Gravatar #9 - reefermadness  
6. mar. 2011 11:48
#8 - Havde overvejet en "play with stranger" funktion, men det ville ikke give meget mening uden en chat, så det lader sig vente.


Var der nogle af jer der prøvede at køre musen over de diverse IM logoer i toppen?
Gravatar #10 - Makey
6. mar. 2011 13:09
Niceness, helt sikkert et fedt koncept, feedback:
Positionen af X og O billederne i Tic Tac Toe er lidt off, de er ikke centretet verticalt, og måske er de også en pixel for langt til venstre, dunno.
Tekstboblerne er meget søde, men skriften er for lille og tekstboxen alt for stor til de kortere linjer.
Når du trykker på linket må det gerne automatisk kopiere linket til clipboard, så du kun skal trykke CTRL+V for at give det videre, læs f.eks. her. Eventuelt en "Click here to copy link to clipboard". Om ikke andet er det træls at skulle markere hele linket. Jeg kan se at den hurtigt markerer hele linket for mig, men derefter går tilbage i teksten der hvor klikkede (Chrome, OS X).
Få lavet en maskot/figur som repræsenterer din side, har ikke lige nogle konkrete ideer, men en stickman agtig figur du kan bruge på siden, noget der ilustrerer hvor legende nemt det er at spille casual spil med vennerne via dit site.
Gør det muligt at indsætte talværdier i Castle Wars, det er godt nok mange clicks man skal igennem for sige lidt når vinden skifter. Men nice musik når man vinder :D
I Runner ville det være rart at kunne se scores, så man ikke selv skal holde øje med hvem der har vundet hvor mange spil. Dette gælder forresten også for de andre spil.
Og apropos, så nogle stats over hvem der har spillet flest spil og hvor mange de har vundet etc. Hvis du beslutter dig for at lave fora og mulighed for login etc. på et tidspunkt.
Gravatar #11 - stekkurms
6. mar. 2011 13:12
reefermadness (3) skrev:
Men det kræver at jeg får fat i flere IP-adresser / servere, hvilket budgettet ikke lige er til pt.
Du kunne prøve med IPv6, så kan adresserne vistnok fås gratis, hvis man kan leve med at skulle sætte en tunnel op. Du kan indbygge en teredo klient direkte i din software til de klientamskener, der ikke har IPv6 support. Du skal selvfølgelig sikre, at klienten afprøver alle tre muligheder, og automatisk bruger den mest pålidelige.

For bedre pålidelig bør du så sætte et teredo relay op på din server. Den kræver ingen ekstra IP, blot en UDP port. Og dermed har du god forbindelse til klienten uanset om der bruges teredo klient i OS eller i din applikation.

fjols (4) skrev:
Hvis du kender et program der kan tjekke det for mig
nmap.

Kør nmap imod en ekstern maskine, hvor alle porte er lukket. Hvis maskinen og firewallen reagerer på samme måde på en lukket port vil det selvfølgelig ikke virke. Derfor bør du prøve med to eksterne maskiner, en hvor alle porte er lukket, og en der simpelthen ikke svarer.

reefermadness (3) skrev:
PS. Nogle der ved om der er andre porte som typisk er åbne på skoler / business netværk ?
554 er værd at prøve.
Gravatar #12 - trylleklovn
6. mar. 2011 13:14
SSL 443 porten er typisk også åben.
Gravatar #13 - reefermadness  
6. mar. 2011 13:30
Nå ja SSL porten burde være oplagt at (mis)bruge til dette formål..

Er der nogle der har en idé om hvor populært det er at blokere 8080 ?

Den bruges vel hyppigst til administative formål..
Gravatar #14 - kasperd
6. mar. 2011 19:43
stekkurms (11) skrev:
Du kan indbygge en teredo klient direkte i din software til de klientamskener, der ikke har IPv6 support.
Kunne nok nemt implementeres hvis programmet kun gør brug af UDP trafik. Men det lyder som om det er TCP, og så ville den idé kræve at programmet havde indbygget sin egen TCP stak, hvilket muligvis er overkill.

stekkurms (11) skrev:
554 er værd at prøve.
Jeg mener at jeg tilbage i 2006 kom forbi et enkelt (eller to) netværk hvor den port var åben og de fleste andre porte var lukkede. Men jeg tror ikke jeg har set det siden.

Hvis man leder efter noget som man kan være sikker på er åbent, så er DNS en mulighed. Men det er igen overordentligt besværligt hvis man har brug for TCP. Selv hvis det behov man har kunne håndteres med UDP, så er det ikke let at gøre det over DNS.

Sagen er, at selvom DNS næsten altid er åbent, så er det ikke ensbetydende med, at man bare kan sende trafik til port 53 og forvente at det kommer igennem.

Der er mange udfordringer hvis man vil bruge den slags, for DNS servere kan opføre sig mærkeligt. Og netværk kan opføre sig mærkeligt, så man ikke nødvendigvis kan snakke med den DNS server man har tænkt sig.

Der findes netværk som åbner for UDP port 53 til hele verden, men der findes også netværk hvor det ser ud som om UDP port 53 er åben, men i virkeligheden hijackes alle pakker og sendes til en lokal DNS server som så spoofer IP på svaret. Så, du tror måske du kommunikerer med din egen server, men det gør du ikke. Hvis ikke pakken indeholder en gyldig DNS forespørgsel til et domæne hvor din server er autoritativ, så ser du den aldrig.

Selvom DNS kræver både UDP og TCP, så findes der netværk hvor kun UDP port 53 er åben og TCP port 53 er lukket. På sådan et netværk vil man kun kunne lave DNS opslag så længe svaret er højst 512 bytes.

Der findes DNS servere som ikke kan håndtere store pakker korrekt. F.eks. har jeg set et eksempel på en server, som ikke kunne håndtere en TXT record på mere end 127 bytes, selvom den tilladte størrelse er 255 bytes.
Gravatar #15 - reefermadness  
6. mar. 2011 21:07
Jeg har nu ændret to af spillene (Castle wars og runner) til at køre på port 443 istedet for 8030.. Du må meget gerne tjekke om det hjalp fjols :-)

Tictactoe kører stadig på 8020... Skal lige finde ud af et godt alternativ til denne
Gravatar #16 - fjols
6. mar. 2011 21:12
Port 443 virker, men nu har jeg bare ingen at spille med :)
Gravatar #17 - kasperd
6. mar. 2011 21:25
reefermadness (15) skrev:
Jeg har nu ændret to af spillene (Castle wars og runner) til at køre på port 443 istedet for 8030.
Det behøver vel ikke være enten eller. Serveren kunne lytte på begge porte, eller du kunne bruge porforwarding eller xinetd til at dirigere requests fra den ene port til den anden.

Så kunne spillet når det starter afprøve begge for at finde ud af hvilken der virker.
Gravatar #18 - reefermadness  
6. mar. 2011 21:28
#17 - Tjoeh, men det kan vel ligeså godt bare køre på en enkelt port..

Nogle forslag til hvilken ledig port jeg kan bruge til den anden server?
Gravatar #19 - reefermadness  
7. mar. 2011 20:37
Kan jeg få jer til at teste en bette ting?

gå ind på http://gameinvite.net/games/fpstest.html og kør flash filen i et par sekunder, lig venligst mærke til hvad FPS og RTT er på.. Skriv resultaterne her, behøver ikke at køre mere end et par sekunder..

Lig også mærke til om "hjulet" laver et hak når der kommer en ekstra prik over den..
Gravatar #20 - Hubert
7. mar. 2011 20:47
FPS svinger mellem 23 og 25
RTT svinger mellem 33 og 45
Gravatar #21 - fjols
7. mar. 2011 20:49
FPS mellem 20 og 21
RTT 46-50
Intet hak i hjulet synes jeg.

Ubuntu + Chrome.
Gravatar #22 - MiniatureZeus
7. mar. 2011 20:56
FPS mellem 6-7, hopper ca. hvert 5. sekund op på 14-15
RTT ca. 67, hopper ca. hvert 10-15. sekund op på 120-130 (ikke samtidig med FPS)

Hjulet hakker ikke

Safari / Mac OS X
Gravatar #23 - kasperd
7. mar. 2011 21:13
reefermadness (19) skrev:
Kan jeg få jer til at teste en bette ting?

gå ind på http://gameinvite.net/games/fpstest.html og kør flash filen i et par sekunder, lig venligst mærke til hvad FPS og RTT er på.. Skriv resultaterne her, behøver ikke at køre mere end et par sekunder..
De er der slet ikke når jeg går ind på siden.

Lig også mærke til om "hjulet" laver et hak når der kommer en ekstra prik over den..
Hjulet hakker overhovedet ikke. Rent faktisk bevæger det sig overhovedet ikke. Til gengæld er der ikke nogen ekstra prik.
Gravatar #25 - reefermadness  
7. mar. 2011 21:39
kasperd (23) skrev:
reefermadness (19) skrev:
Kan jeg få jer til at teste en bette ting?

gå ind på http://gameinvite.net/games/fpstest.html og kør flash filen i et par sekunder, lig venligst mærke til hvad FPS og RTT er på.. Skriv resultaterne her, behøver ikke at køre mere end et par sekunder..
De er der slet ikke når jeg går ind på siden.

Hjulet hakker overhovedet ikke. Rent faktisk bevæger det sig overhovedet ikke. Til gengæld er der ikke nogen ekstra prik.


Der kan gå et par sekunder før den connecter da den først skal modtage en crossdomain policy og så reconnecte... Tager typisk et sted mellem 5 og 10 sekunder..

Men hvis der ikke kommer noget efter f.eks 20 sekunder vil jeg meget gerne høre hvilken browser, os, udbyder og eventuelt hvilket netværk du sidder på (Er det hjemme, arbejde, skole? Ved du noget generelt om opsætningen? er der f.eks deep packet inspection el.lign?)

#24 - Mystisk :S
Gravatar #26 - reefermadness  
7. mar. 2011 22:03
#23 - Kan også ske at den på uheldigvis har har valgt at joine en "optaget" lobby, den vælger et tal mellem 1 og 9999 og smider dig ind i et "rum" med plads til 1 spiller... Prøv at refreshe hvis det sker..
Gravatar #27 - kasperd
7. mar. 2011 22:04
reefermadness (25) skrev:
Der kan gå et par sekunder før den connecter da den først skal modtage en crossdomain policy og så reconnecte... Tager typisk et sted mellem 5 og 10 sekunder..
Jeg opdagede lige at jeg havde efterladt den åben da jeg skrev mit sidste indlæg. Og der er stadigvæk intet sket.

Prøver den at forbinde direkte til serveren udenom den socks proxy, jeg har konfigureret? På det her netværk er den nødt til at bruge proxyen, for ellers er der ingen forbindelse.
Gravatar #28 - Makey
7. mar. 2011 22:24
0-1 FPS (kører meget langsomt rundt)
162-399 RTT
Chrome, Mac OS X, 3G-modem
Gravatar #29 - reefermadness  
7. mar. 2011 22:41
kasperd (27) skrev:
Jeg opdagede lige at jeg havde efterladt den åben da jeg skrev mit sidste indlæg. Og der er stadigvæk intet sket.

Prøver den at forbinde direkte til serveren udenom den socks proxy, jeg har konfigureret? På det her netværk er den nødt til at bruge proxyen, for ellers er der ingen forbindelse.


Hmm det vil jeg lige undersøge, ved ikke om jeg har mulighed for at vælge om den skal køre gennem proxy eller ej..

Gravatar #30 - reefermadness  
7. mar. 2011 22:44
Makey (28) skrev:
0-1 FPS (kører meget langsomt rundt)
162-399 RTT
Chrome, Mac OS X, 3G-modem


Øv.. Så skal jeg ikke regne med at 3G folket bliver glad for mine næste par spil, da de vil være lidt mere realtid end hvad de andre har været... (skydespil og racerspil)

Men fed info, så kan jeg se at jeg bliver nød til at lave en ping test, og eventuelt advare folk med dårlig forbindelse om soggy gameplay :(
Gravatar #31 - reefermadness  
7. mar. 2011 22:52
kasperd, kan du connecte til kryds og bolle spillet på www.gameinvite.net ?

har lige læst noget om at flash' XMLSocket ikke kan tilslutte gennem proxy når porten er mindre end 1024.. vil egentlig gerne lige se om det passer..
Gravatar #32 - arne_v
8. mar. 2011 02:03
reefermadness (13) skrev:

Er der nogle der har en idé om hvor populært det er at blokere 8080 ?

Den bruges vel hyppigst til administative formål..


Officielt er den HTTP alternate port.

I praksis er der ofte en servlet container på den port.
Gravatar #33 - Makey
8. mar. 2011 07:22
Til sammenligning, på skolens netværk:
5-InfinityFPS (mest mellem 20-40)
30-66 (peaker på 110) RTT
Chrome, Mac OS X

Safari:
8-31 FPS
32-64 RTT

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; pl; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
7-InfinityFPS (12-30)
30-50 (peak 108)
Gravatar #34 - kasperd
8. mar. 2011 10:37
reefermadness (31) skrev:
kasperd, kan du connecte til kryds og bolle spillet på www.gameinvite.net ?
Could not connect to server

Jeg må lige prøve at fyre tcpdump op når jeg har lidt bedre tid.
Gravatar #35 - D_V
8. mar. 2011 11:04
#19

http://i55.tinypic.com/t5gb68.jpg

Får også infinity her:

Browser:
Mozilla/5.0 (X11; Linux x86_64; rv:2.0b13pre) Gecko/20110308 Firefox/4.0b13pre

Flash:
Shockwave Flash 10.3 d162
aka, Flash player 10 square preview 3 64bit til linux


EDIT:
Får samme resultat i chrome

EDIT2:
Og i IE8. kørende fra en windows 7 vm.
Gravatar #36 - reefermadness  
8. mar. 2011 11:08
#35 - Well det er vidst en division by zero der er skyld i det infinity halløj der.. Måske flashplayeren der reporterer 0 i framerate..

Anyways det vigtigste er alligevel RTT..


Tror jeg har det info jeg har brug for... Men kunne være rart hvis nogle fra det store udland kunne køre testen også (USA, Australien, øst europa og asien for at være mere specifik)
Gravatar #37 - Makey
8. mar. 2011 11:12
reefermadness (36) skrev:
Tror jeg har det info jeg har brug for... Men kunne være rart hvis nogle fra det store udland kunne køre testen også (USA, Australien, øst europa og asien for at være mere specifik)

1. Post on /b/
2. Promise tits
3. ???
4. PROFIT!
Gravatar #38 - D_V
8. mar. 2011 11:16
#36

10ms fra en universitets linie i UK,

Folk sover i usa i øjeblikket, så kan ikke lige få nogen til at tjekke der...
Gravatar #39 - reefermadness  
8. mar. 2011 11:56
Makey (37) skrev:
1. Post on /b/
2. Promise tits
3. ???
4. PROFIT!
'

Tør jeg kun gøre med lukkede øjne, hvilket besværliggør processen en smule ..
Gravatar #40 - fjols
8. mar. 2011 13:00
Jeg kan prøve via firmaets VPN forbindelser i USA og asien når jeg får fixet min konto om et par dage.
Gravatar #41 - OxxY
8. mar. 2011 15:19
33FPS
30 ms

IE8/xp-sp3 fra min arbejdspc. (og en spritny flashplayer som adobe insisterede på jeg intallerede her i morges).
Gravatar #42 - stekkurms
21. mar. 2011 08:09
kasperd (14) skrev:
Kunne nok nemt implementeres hvis programmet kun gør brug af UDP trafik.
Kører de her spil over UDP? Det lyder mere som TCP. Kan de nemt ændres så de kan køre over UDP? Hvis vi snakker realtime spil, så er UDP nok under alle omstændigheder et bedre valg.

reefermadness (18) skrev:
Tjoeh, men det kan vel ligeså godt bare køre på en enkelt port..
Det kommer vel an på hvor vigtigt det er at få det til at virke for så mange som muligt. Måske er der en bruger på et netværk der kun tillader port 443 og en bruger på et andet netværk, der kun tillader port 8080. Burde de ikke kunne spille med hinanden? Og burde de ikke have lov til at spille andet end hvad du lige tilfældigvis havde valgt at placere på den port de kunne tilgå. Det er selvfølgelig ekstra arbejde for dig at få det til at virke, så det er et spørgsmål om, hvor vigtigt du synes det er.
Gravatar #43 - reefermadness  
21. mar. 2011 09:49
#42 Kunne være jeg skulle se på UPD..

Jeg har hørt fra et par Amerikanere at de ikke kunne bruge spillet efter jeg har skiftet port, så det kunne nok være en god idé at have flere, og så prøve nogle forskellige når jeg spillet tilslutter serveren..

Hvordan ville jeg kunne opnå at køre den samme service på flere porte med xinetd ?
Gravatar #44 - fjols
21. mar. 2011 09:53
Kan du ikke bare lave flere entries til samme service på forskellig port?
Gravatar #45 - markjensen
21. mar. 2011 10:11
stekkurms (42) skrev:
Hvis vi snakker realtime spil, så er UDP nok under alle omstændigheder et bedre valg.


I datanet sagde vores lærer (jeg mener det var ham - det kan dog have været en anden) at det ikke længere kan betale sig at bruge UDP til spil.
Gravatar #46 - D_V
21. mar. 2011 10:30
#43

Den eneste måde du lige kan klare den på, er ved at have en fælles protokol der initialisere forbindelsen.

Eg. lidt ala, i http hvor du spørg efter en specifik side.

Vil dog anbefale at du tilbyder både UDP og TCP, så den falder tilbage på TCP hvis det ikke kan lade sig gøre at opnå forbindelse med UDP.
Gravatar #47 - kasperd
21. mar. 2011 20:29
reefermadness (43) skrev:
Hvordan ville jeg kunne opnå at køre den samme service på flere porte med xinetd ?
Hvis du har en service kørende på én TCP port, så kan den nemt gøres tilgængelig på endnu en TCP port ved at redirecte med xinetd (eller ved at redirecte på anden måde).

Jeg har selv brugt dette til at gøre ssh på min server tilgængelig via en ekstra port.

service second-ssh
{
type = UNLISTED
flags = REUSE
socket_type = stream
protocol = tcp
port = (portnummer her)
wait = no
redirect = (hostnavn her) 22
user = root
disable = no
}


Da jeg senere fandt ud af at sshd rent faktisk også kan startes direkte fra xinetd lavede jeg det om på følgende måde

service second-ssh
{
type = UNLISTED
flags = REUSE
socket_type = stream
protocol = tcp
port = (portnummer her)
wait = no
user = root
disable = no
server = /usr/sbin/sshd
server_args = -i
}


Hvis dine spil er afhængige af at alle TCP forbindelserne håndteres af en enkelt process (f.eks. fordi det er den måde du håndterer tilstand på), så vil sidstnævnte metode med at starte servicen fra xinetd åbenlyst ikke virke.

Men i stedet for at blot binde en enkelt socket til en port, så kan din service også blot selv binde sig til to porte og så acceptere forbindelser på begge. Det er muligvis det nemmeste.

Jeg ved ikke om redirection gennem xinetd kan bruges til UDP. Men til UDP kan du også bare binde til to porte.

Den største udfordring er sådanset hvis du vil have to forskellige processer til at modtage trafik fra to forskellige spil, som går til samme port. Hvis du kun har en enkelt IP at køre det hele på er du nødt til at have en process der tager imod trafikken og fordeler den.

Det ville være nemt at skrive et program til at fordele UDP pakker til forskellige processer, hvis blot hver pakke indeholder oplysninger om hvilket spil den hører til.

markjensen (45) skrev:
I datanet sagde vores lærer (jeg mener det var ham - det kan dog have været en anden) at det ikke længere kan betale sig at bruge UDP til spil.
Hvad havde han tænkt sig at bruge i stedet?

Hvis vi snakker om realtime spil er TCP ikke specielt velegnet. Og UDP-Lite er ikke ret forskelligt fra UDP. I praksis tror jeg ikke det vil gøre nogen forskel om man bruger UDP eller UDP-Lite. Der er flere transport protokoller, men jeg kan ikke komme i tanke om andre som med nogen form for rimelighed kan bruges til realtime spil.
Gravatar #48 - onetreehell
21. mar. 2011 20:59
Jeg vil nok fraråde dig at bruge UDP. Du får ingen garantier med UDP. Du kan få pakker i forkert rækkefølge, tabe pakker, få duplikerede pakker(!)... Desuden er der heller ikke noget i UDP til at undgå congestion [CITATION NEEDED], så folk kan finde på at droppe UDP pakker fordi de er røvhuller.
Det ender nok alligevel, hvis du bruger UDP, at du mere eller mindre ender med at implementere TCP ovenpå UDP.
Gravatar #49 - markjensen
21. mar. 2011 21:00
kasperd (47) skrev:
Hvad havde han tænkt sig at bruge i stedet?


Det er ret lang tid siden jeg havde datanet, men hvis jeg husker korrekt, så mente han at hastigheden i tcp var fin, og at spil bruger det i dag af bl.a. de grunde som onetreehill nævner. Jo mere jeg tænker over det, jo mere i tvivl bliver jeg dog. Jeg kan prøve at spørge nogle af de andre, men jeg tvivler på at de kan huske det.
Gravatar #50 - kasperd
21. mar. 2011 21:44
onetreehell (48) skrev:
Jeg vil nok fraråde dig at bruge UDP.
Jeg vil råde til at man gør sig klart hvilke behov man har og så vælger den protokol der passer bedst til de behov.

Du får ingen garantier med UDP.
Du er garanteret en latenstid som er mindst lige så god som TCP og uden den store variation i latenstiden som følger med TCP.

Du kan få pakker i forkert rækkefølge, tabe pakker, få duplikerede pakker(!)...
Et spørgsmål man er nødt til at stille sig selv er om en pakke stadigvæk er brugbar hvis den kommer for sent. Hvis en forsinket pakke ikke kan bruges til noget, så er UDP et bedre valg. Hvis en pakke altid kan bruges uanset hvor sent den kommer, så er TCP et bedre valg.

Hvis duplikerede pakker eller pakker i forkert rækkefølge er et problem, så kan man simpelthen blot sætte en tæller på sine pakker. Hvis man modtager en pakke med en større tællerværdi end den sidste man accepterede, så accepterer man den netop modtagede pakke, ellers kasserer man den.

F.eks. kan det være at man sender beskeder om en modstanders position hver gang han flytter sig. Hvis man sender opdatering 1 og opdatering 2, men opdatering 1 gik tabt, så er det ligegyldigt, når opdatering 2 er nået frem.

Havde man brugt TCP ville der ske det at opdatering 2 ikke bliver leveret til applikationen fordi opdatering 1 ikke er nået frem endnu. På et tidspunkt bliver opdatering 1 retransmitteret, men tjener intet formål fordi opdatering 2 bliver leveret til applikationen samtidigt.

Hvis man bruger TCP er man desuden selv nødt til at implementere message boundaries da TCP blot implementerer en stream.

Desuden er der heller ikke noget i UDP til at undgå congestion
Nej, og UDP bør sjældent bruges hvis man har brug for at overføre så mange data, at congestion er et problem. TCP er heller ikke perfekt, men til overførsel af store datamængder hvor man ikke har skrappe krav om latens er TCP trods alt det bedste valg.

folk kan finde på at droppe UDP pakker fordi de er røvhuller.
Hvis det argument tæller, så kan vi lige så godt slukke for Internettet. Et af de bedste bud på at forbedre på TCPs håndtering af congestion er ECN, og det er der også netværk der dropper. I øvrigt kører DNS stort set altid over UDP. Og jeg har set mange netværk der dropper DNS over TCP. Jeg har aldrig set et netværk, der droppede DNS over UDP.

Det ender nok alligevel, hvis du bruger UDP, at du mere eller mindre ender med at implementere TCP ovenpå UDP.
Problemet er at hvis det man har brug for ikke er TCP men kun en del af det TCP implementerer, så kan man ikke tage TCP og kun bruge det man har brug for. Med UDP kan det trods alt lade sig gøre at implementere de ting fra TCP som man har brug for.

Ovenpå UDP kan man trods alt implementere de features fra TCP som man har brug for.

Det bedste ville være at vælge en protokol som implementerer noget der ligger et sted imellem TCP og UDP og som implementerer præcist hvad man har brug for. Men jeg kan ikke huske hvad den protokol hedder, og den er der mange netværk der dropper.

markjensen (49) skrev:
så mente han at hastigheden i tcp var fin
Problemet med brug af TCP til realtime applikationer er at så snart en enkelt pakke er gået tabt, så vil alle efterfølgende pakker blive forsinket indtil den tabte pakke er blevet retransmitteret for at garantere ordning på pakkerne.
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login