...
Szinkronizációs problémák: a példánál maradva, ha mindkét program egyszerre próbál szerver lenni, majd kliens, és a váltáskor nincs olyan időintervallum, melykor már egyikük másik módra váltott, de a másik még nem, akkor nem tudnak kapcsolódni. Persze nem egyszerre történik meg a váltás a két programon, de a hálózati átvitelre, a bejövő üzenet észlelésére és a visszacsatoló válaszküldésre is kell az idő. Ha túl gyorsan vált szerver/kliens üzemmódot a program, akkor nincs idő a kapcsolatépítésre, ha túl lassan, akkor sokáig tarthat a kapcsolódás. Nyilván kettő futó alkalmazás esetén elég egyszer kapcsolódni, aztán már ezzel nincs gond. Adott több futó alkalmazás, mondjuk 100 darab kliens és 1 szerver (mindegyikük egyértelműen kliens ill. szerver). Ha minden kapcsolat ugyanazt a portot kívánja használni, éspedig TCP-vel, akkor szükségszerű a folyamatos fel-le csatlakozás, itt már gond lehet a lassúság. Egy alkalmazás nem kötheti le túl sokáig a szervert. Túl rövid kapcsolatok esetén viszont egyszerre túl sok kliens próbálhat kapcsolódni sikertelenül, ami szintén lassulást eredményez. Az eddigiek még nem tényleges szinkronizációs gondok. De ha az alkalmazások számára elérhető hálózati sebesség más, akkor előfordulhat torlódás, az egyik gép már régóta válaszra vár, míg a másik gép meg még csak a csomagok felét kapta meg. Több alkalmazás esetén még inkább bonyolódhat a helyzet. Ha sok adat továbbítására van szükség, akkor egy lassú kliens hosszú időkre foghatja a szervert.
UDP esetén gondoskodni kell a sorrendiségre utaló információ elküldéséről.
| Viewtracker |
|---|