TRtcUdpClient problem

[JeremyK]

Has much changed in rtcUdpCli since version 3.32? I recently decided to renew my subscription to RTC having not updated for some time, as the application has been working fine.

I noticed I had to install the rtc Raw package to get the components I use (TRtcUdpClient, TRtcUdpServer, TRtcTcpServer, TRtcTcpClient) to communicate with some electronic hardware.

The TRtcUdpClient/TRtcUdpServer are used to locate the various devices on the network, and whereas 3.32 got a reply from all of the devices, 4.35 is only getting replies from the odd one here and there.

If these components have been superseded, what should I be using instead?

Thanks
Jeremy

[D.Tkalcec (RTC)]

All low-level UDP and TCP/IP components (TRtcUdpClient, TRtcUdpServer, TRtcTcpClient and TRtcTcpServer) are being "phased out" and will most likely be removed from one of the upcoming RTC SDK releases. If possible, you should switch to higher-level RTC SDK components, which work over HTTP/S (TRtcHttpClient and TRtcHttpServer).

A lot has changed in the past two years. The low-level socket access layer has been completely redesigned and rewritten to achieve platform independence. During that process, a lot of the old units have been completely removed, a numer of new units were added and some old units have been rewritten and renamed. Include files have also moved into subfolders. As a result, there is no easy way to find out which change might be causing UDP datagrams to get lost more often now than before.

If you are bound to using UDP because of your hardware requirements, your best bet is probably to continue using the RTC SDK v3.32 for all applications which need UDP support. Format used by RTC remote functions is compatible between RTC SDK v3.32 and RTC SDK v4.35 (at least for features available in both releases), so you should be able to mix old and new RTC Clients and Servers.

NOTE: UDP uses a simple transmission model without implicit handshaking. This is one of the reasons why UDP is unreliable (datagrams may arrive out of order, appear duplicated, or go missing without notice). UDP assumes that error checking and correction is either not necessary or performed in the application, avoiding the overhead of such processing at the network interface level.

Best Regards,
Danijel Tkalcec

[JeremyK]

All low-level UDP and TCP/IP components (TRtcUdpClient, TRtcUdpServer, TRtcTcpClient and TRtcTcpServer) are being "phased out" and will most likely be removed from one of the upcoming RTC SDK releases. If possible, you should switch to higher-level RTC SDK components, which work over HTTP/S (TRtcHttpClient and TRtcHttpServer).

I use TRtcTcpClient and TRtcTcpServer to talk to some electronic hardware which uses some C networks to provide TCP/IP comms. I cannot change this, because they are already in the field. So, I'm not using http type of communications, so can I use TRtcHttpClient and TRtcHttpServer to just talk direct TCP/IP like I do at the moment (I haven't looked at them)? If not, then there was no point me upgrading to the later version, I just thought it best so I can continue to pick up any improvements, but it sounds like there won't be any or are you just talking about the udp component?

If you are bound to using UDP because of your hardware requirements, your best bet is probably to continue using the RTC SDK v3.32 for all applications which need UDP support. Format used by RTC remote functions is compatible between RTC SDK v3.32 and RTC SDK v4.35 (at least for features available in both releases), so you should be able to mix old and new RTC Clients and Servers.

I'm only using the UDP for a very small part of an engineering tool that uses it to search on the network for any devices. The main application uses the other components I mentioned.

NOTE: UDP uses a simple transmission model without implicit handshaking. This is one of the reasons why UDP is unreliable (datagrams may arrive out of order, appear duplicated, or go missing without notice). UDP assumes that error checking and correction is either not necessary or performed in the application, avoiding the overhead of such processing at the network interface level.

I know, I cope with this  and as I say, it's just for an engineers tool but still required and we're getting response from every device using 3.32 but not from 4.35.

Jeremy

[D.Tkalcec (RTC)]

I have released an update for the RTC SDK (v4.52 BETA), which should resolve problems with high datagram packet loss when using UDP connection components and improve TCP/IP connection stability (less disconnects under heavy load). Please download this latest RTC SDK release and let me know if it works for you, or if you still have problems with high UDP datagram loss.

Best Regards,
Danijel Tkalcec

[JeremyK]

I have now been able to try this, and our first on-site tests show it is back to where it was with the 3.32 version, so thank you for the quick response.

[Kevin Powick]

I have released an update for the RTC SDK (v4.52 BETA), which should resolve problems with high datagram packet loss when using UDP connection components and improve TCP/IP connection stability

Does this mean that you have changed your mind and will not be phasing out the low-level TCP/IP and UDP components?  As pointed out by Jeremy K.,  These can be very useful in some situations.  If removed from futre versions RTC SDK,  one will be forced to rely on multiple, different component sets to achieve what is currently possible.

If you are still planning to remove them, can you tell us why?

Thanks,

[D.Tkalcec (RTC)]

I can leave raw TCP/IP and UDP components included in the "rtcSDK_RAW" package and continue maintaining them for Windows, but their functionality is based on the asynchronous WinSock API, so I most likely won't be able to port them to other (non-Windows) platforms.

Other than that, raw TCP/IP and UDP components (TRtcUdpClient, TRtcUdpServer, TRtcTcpClient and TRtcTcpServer) are the only RTC communication components which do NOT extend TRtcDataClient and TRtcDataServer components, because of which they can NOT be linked with ANY other components from the RTC SDK, but can ONLY be used for implementing custom protocols - from scratch.

Best Regards,
Danijel Tkalcec