ufff ...
I made heavy test with udp too and results are ugly :
I have Sent in loop (this result as threads) 150, 300 and 3000 messages.
Sending threads using semaphores and were limited to 15, 150 and 1000
threads.
All were sent between two comp with nice connections and 180 ping and I lost
tooo much messages :(
worst results were that from 300 sent messages have received 180 or from
3000 sent messages have received 1600.
Of course, in real environment I would not send that much messages at least
not that much between two same hosts but tests said that data lose is just
unaceptable.
Any idea how I can check is data sent with udp ? (except to send on another
connection confirmation message with id of message and to keep in queue till
answer is received, anyway, answer can fail too ...)
server is created with :
FRcvUdp.BufferSize := 32768;
FRcvUdp.OnUDPRead := rcvUDPServer;
and client is simple :
sendUdp.SendBuffer(FdestIP, FdestPort, FData);
messages were small, 20-30 Bytes (reall messages will be bigger and variable
size, expected average 300-400 Bytes).
"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message
news:4595edad$1@newsgroups.borland.com...
>
> "Dejan Petrovic" <dejanbng@removeThis.ztbclan.com> wrote in message
> news:4595cde3@newsgroups.borland.com...
>
>> wondering what indy and XP Home edition will do when I trying
>> to open let's say 1000 connections in time :
>
> If you exceed the OS's limits, you will get exceptions raised by Indy
> when sockets cannot be created/opened anymore.
>
>> 1. Open first 40 connections and raise error on all other threads
> which try
>> to open more connections ?
>
> Yes.
>
>> 2. windows internaly put on wait rest 960 connections till first one
> is
>> closed and process one by one ?
>
> No.
>
>> 3. allow all 1000 to send ?
>
> Very doubtful.
>
>> Actually I don't know do I shall :
>
> A pool sounds like a good idea. That way, you are limited to what is
> actually available, and your code can throttle itself according to
> availability.
>
>> sending pseudo code is simple and shall be fast :
>
> You may also consider using UDP instead of TCP, since there are no
> connections in UDP.
>
>
> Gambit
