@penengo
TIdSync still works, but is deprecated because TThread::Synchronize() with an anonymous procedure accomplishes the same thing that TIdSync was originally intended for. Read Embarcadero's documentation for How to Handle Delphi Anonymous Methods in C++.
I want to replicate this site : https://hide.me/id/proxy to work in my internal network. From where i must begin?
@rlebeau Is support for OpenSSL 1.1.0 coming? I managed to successfully build iOS simulator dylibs for 1.1.0f, and tweaked IdSSLOpenSSLHeaders so it would load the new version, however it failed to bind to a number of routines, namely: SSL_load_error_strings, SSL_library_init, SSLeay_version etc
at least I assume it failed to bind to them because that's what WhichFailedToLoad reports
Complete list: SSL_load_error_strings,SSL_library_init,SSLeay_version,SSLeay,CRYPTO_lock,CRYPTO_num_locks,CRYPTO_set_locking_callback,CRYPTO_set_id_callback,ERR_free_strings,EVP_MD_CTX_init,EVP_CIPHER_CTX_flags,HMAC_CTX_init,HMAC_CTX_cleanup,CRYPTO_mem_leaks,CRYPTO_set_mem_debug_functions,OpenSSL_add_all_algorithms,OpenSSL_add_all_ciphers,OpenSSL_add_all_digests,EVP_cleanup,sk_num,sk_new,sk_new_null,sk_free,sk_push,sk_dup,sk_find,sk_value
I found the best performance by setting the client (sender) buffer to 0, and flat out sending the output message twice.
Wondering what I can tweak and what status I can look at to see what's happening.
I check the integrity of what I rcv.. it is good.
@robert010 are you sending the raw wave data as-is, or are you wrapping it in something like RTP?
not using any rtp type protocol,, very simple slow stuff, just an index per increment.
@robert010 that is a defining charactertictic of UDP, you can't guarantee packet delivery, or guarantee timing. Packets may be dropped, packets may take different network routes to the target, etc. You have to be prepared to handle that. Put an incrementing sequence number in the packets, require receivers to ACK packets received, re-send any packets that are not ACKed, reorder received pacekts, etc. Of course, this only applies if you require data integrity.
it is a visual wave,, so you see what is happening.
Data is for visualization only so occasional glitch would be ok
I know the disadvantages of udp.
explain multicasting
is there a feedback on the os stack status out of indy
@robert010 no. Have you clocked the outgoing packet sends to see if any delays are occuring? Have you queried/tweaked the socket's outgoing buffer size at all? Is your sending machine doing other things at the time of sending that might take CPU time away from handling network requests?
@robert010 then get a faster router. Or maybe the issue is in the receiver's wireless, not the router's wireless (again, you should monitor the network traffic on the receiving side). Not much you can do about it in code, unless you play around with QOS settings to give your packets higher priority on the network.
if you have a simple way of doing multiple tcp connections, I am all ears. Best I can think is to use a initial UDP to establish the active port number for a connection.
In any case, do try multicasting first, that is better on network traffic than broadcasting since it is opt-in (receivers actively register with the network to receive packets) rather than "anyone want it?" (dumping packets on the network and anyone who happens to be listening can receive). That might make a difference in reducing router overhead and prioritizing packets, before you resort to switching to TCP
@robert010 you might want to read up on what multicasting is from an API perspective: Multicast Programming, Multipoint and Multicast Semantics, Protocol-Independent Multicast and Multipoint, etc. There is a lot involved beyond simple UDP, but the jist is that multicasting allows you to send a packet once (to a multicast group IP) and it is delivered only to recipients who have joined the same multicast group (have notified the network that packets directed to the group IP should be delivered to the receiver's listening socket).