Ik ben met een client / server programma bezig en er wordt via TServerSocket (tcp) gecommuniceerd. De server staat ingesteld op NonBlocking. Het versturen aan de client kant gebeurt via
clientSocket->SendText("datahier");
Zodra de client klaar is met zenden stuurt deze een (sluit-)herkenningsstring door. Dit werkt met kleine hoeveelheden data perfect.
Enkele (losse) strings kunnen aan de serverkant in 1 keer gelezen worden door
Socket->ReceiveText().
Zodra er aan de client kant in een for-loop 1000x zo'n string verstuurt wordt, vindt aan de server kant meerdere keren het event ClientRead plaats. Die 1000 strings passen dus niet in 1 keer in de buffer van de socket. Dit is nog geen probleem voor mijn programma, maar zodra ik dus nog meer strings ga versturen >2500 komt het (sluit-)herkenningsstring niet meer binnen.
Kan het zo zijn dat er gegevens bij het versturen over het netwerk nooit aankomen, wanneer er teveel verstuurd wordt en dus ontvangen moet worden?
Nu achteraf heb ik door dat ik het beter de ServerSocket op Blocking had moeten zetten en de gegevens in en een aparte Thread had moeten inlezen.
clientSocket->SendText("datahier");
Zodra de client klaar is met zenden stuurt deze een (sluit-)herkenningsstring door. Dit werkt met kleine hoeveelheden data perfect.
Enkele (losse) strings kunnen aan de serverkant in 1 keer gelezen worden door
Socket->ReceiveText().
Zodra er aan de client kant in een for-loop 1000x zo'n string verstuurt wordt, vindt aan de server kant meerdere keren het event ClientRead plaats. Die 1000 strings passen dus niet in 1 keer in de buffer van de socket. Dit is nog geen probleem voor mijn programma, maar zodra ik dus nog meer strings ga versturen >2500 komt het (sluit-)herkenningsstring niet meer binnen.
Kan het zo zijn dat er gegevens bij het versturen over het netwerk nooit aankomen, wanneer er teveel verstuurd wordt en dus ontvangen moet worden?
Nu achteraf heb ik door dat ik het beter de ServerSocket op Blocking had moeten zetten en de gegevens in en een aparte Thread had moeten inlezen.