>Which version of Indy are you using?
The Indy 10 version that came with Delphi 2006.
>You must be using an older version then. In the current Indy 10 shapshot,
>TIdUDPServer uses a separate thread for each individual Binding, much like
>TIdTCPServer does. This allows multiple Bindings to receive data
>simultaneously now. Older versions used a single thread to manage all
>Bindings in a serialized manner.
That sounds great! Exactly what I need. I'm just wondering how it was possible to realize this? From the other posts in the newsgroups I got the impression that the UDP connectionless nature didn't make this possible? Or is it just as simple as looking at the source ip/port combination and calling it a "connection"?
Does it come with a performance penalty? Is there now a point in the Indy code where the incoming packet is checked with a list of running threads by comparing source ip/port combination? Doesn't that involve some critical section stuff that slows down the code? (although benefiting from the dual core)
This is vital to my application because I need to pass through as many UDP packets as possible (early test indicate that 3 ghz dual core, tested internally, so without network limitation, can handle about 3000 kilobyte per second of 138 byte incoming UDP packets).
The only thing it needs to do is forward the UDP packet to another IP/Port which is looked up in a list. Is it possible to have some local variables hooked up on every binding/thread, as is the case with the TCP version? So can I make a derative ContextClass?
Should I be using Indy for this at all? I'd like the bottleneck to be Windows/network, not my software. I did try the Indy UDPmappedport component, but looking at the source this isn't meant for fast applications, since an onject is created and destroyed for every incoming packet. BTW, as you might have guessed I'm talking about a VoIP application here...
