Binary message compatibility broken in 1579 RO/SDK Delphi

Remoting SDK
1

After upgrading to 1579 (from 1573) of RO/SDK for Delphi, an old iOS App developed in Xamarin stopped working with a “Invalid stream format”. This is reported from several customers. There are no changes in the message structures used. Is there a chance for that 1579 broke the binary message compatibility?
The iOS App will not be updated, so this is eventually end of life for it.

2

Hi,

I don’t see any significant changes in code between .1573 and .1579.

Can you give more details, pls:

  • is this error is raised on client or server side?
  • you have specified Delphi tag so error is raised in Delphi app. Am I correct?
  • what exactly error message was raised? we don’t use Invalid stream format error message in Remoting SDK for Delphi so I can’t locate where is this error was raised.
  • what messages (BIN, SOAP, POST, JSON, etc) are used?
  • any other details that will help to us detect [and reproduce] this error?

You can drop email to support@ for keeping privacy.

try to put

{$DEFINE USE_RODL_FORMAT_XML}

into RemObjects_user.inc and launch C:\Program Files (x86)\RemObjects Software\Build\install_RO.cmd with admin rights.

rebuild your Delphi app. will it solve this case?

3

The error is on the client side. It has not changed since 2016.
The server side is Delphi 11
The message is BIN (we use JSON for all new clients)
The correct message is “Invalid string lenght read from stream”. This is a messaeg we have ssen before when we have added fields to classes that are streamed with BIN message (client not updated).

4

Hi,

I see this error in Remoting SDK for .NET.
it is raised at reading AnsiString or Utf8String when their size is bigger that whole stream length. usually it can mean that items in RODL were changed.

Can you check your code and confirm that your RODL wasn’t changed since 2016?

5

The RODL has changed many time since 2016, but it has not affected this application before. Only thing now is that we upgraded to 1579 on the server side.
Today I also got a problem in a Delphi client application for a customer (not changed for many years as well). I don’t know the detail of that yet, but we had to revert to an earlier version (before 1579). It was also using the BIN message type, so I assume it’s the same problem (I don’t have an error message in this case).

6

Hi,

It would be great if you could capture server response that causes problem with outdated delphi client.

comparing these responses from server compiled with 1573 and 1579 will show reason for this failure.

You can use message.OnWriteToStream event for saving server-side responses

7

FTR, many changes in the RODL might sneak thru without breaking it, but in theory, any change to a structure (complex type) or a method/event signature is a breaking and incompatible change and needs to be handled by clients and servers at the same time.

8

I’ll look further into this next week, but as far I know now, the only change is upgrade from 1573 to 1579. But, I’ll double check if something else has been going on.
For older Delphi based clients I can just update, and at the same time change to JSON message to avoid this in the future. We never removes or renames properties, but are adding. The BIN message does not handle added properties - I guess that is just by design.

9

What channels are you using?