Very nice article.
Notice that your function SendDataStream() will not work for $Length(stream)>$$$MaxString
For this, you will need to split parts at sending, mark with an index and rebuild them on the reviver side, according to the index.
Some additional notes:
1. If you have many changes (variations) in query structure (e.g. using different column names, or different conditions on the WHERE clause) dynamic SQL is the choice. However, if your queries do not change in structure, only parameters than embedded SQL will be a better choice (e.g. select id for ref.table where name='name')
2. Embedded SQL build the cached query ONCE while you compile, embedded SQL build and compile a cached query every time your SQL structure changes.
2. Speed of dynamic SQL will be identical to embedded SQL (over time) since most of the possible SQL combinations will have cached queries in place - each time you compile a class/table, its "cached queries" are purged (so expect to have slight degradation after releases or changes in class/table)
3. In case you can use embedded SQL consider giving your client access to a VIEW or a SP (instead of doing SQL against the original table). This way changes you do in class/table will not affect the client
4. As mentioned, security is very important to notice: if you intend to let the client send & execute (dynamically) any SQL, try to limit this for a specific table and sanitize the input to avoid potential "SQL injection" (using s SP with parameter is a good way to secure your backend)
Intersystems UDP implementation (e.g. EnsLib.UDP.OutboundAdapter) is assuming that any stream<MTU size: it uses stream.OutputToDevice() so it will not work with streams>MTU
when splitting parts, consider packet can arrived at random order, so you should "collect" them at receiver, then build the incoming message according to the correct order when you know you have them all