.Net client — Invalid TCP frame received

Meanwhile, we’re doing testing with the .Net client on two local databases, and we’re getting:

[08,11:26:19.922,ERROR] TcpPackageConnection: [, L127.0.0.1:63461, {3d4d209b-2663-4e3a-8e79-8976147e19f0}]. Invalid TCP frame received.
EventStore.ClientAPI.Transport.Tcp.PackageFramingException: Package size is out of bounds: 111038993 (max: 67108864). This is likely an exceptionally large message (reading too many things) or there is a problem with the framing if working on a new client.

What immediate problem causes this, what’s its root cause problem and how do we avoid it in the future.

We’re using client 3.9.5 (latest) with ES 3.9.4 (running on macOS)

What is the operation you are doing? I am guessing its a read. What window sizes are you using?

Yes, we are only reading from that connection. We are reading slices of events of size 4096. I am currently running a test where that number is lowered to 200 (as used here: https://eventstore.org/docs/dotnet-api/3.0.2/reading-events/)

at 4096 events you can get frames that are too large pretty easily.

The thing that is hard to deal with is predicting the size of data and there are maximums (for obvious reasons) on sizes (if not imagine a connection doing a 10mb read and having other requests getting blocked). This is something I have considered revisiting for a long time to change the protocol on. As example to support the breaking up of huge results to many smaller results. The work would not be complicated. It is however a quite expensive change as it will effect every client + versioning issues etc.

That test ran without error.

Ok, that makes sense, I think lowering the slice size solves this for us, thanks.

The slice size also only makes a difference when a subscription is in polling mode or you are directly doing reads (ReadEventsForward etc). If using say a catchupsubscription this is automatically handled and switched to a push model as opposed to polling for the subscription.