Max Attachment Size (.NET & JAVA SDKs)

added workflow::In Progress label

added team::SDK label

changed the description

assigned to @Klaus_Fischer

changed milestone to %PI-2 (Q-3)

added component::SDK - .NET label

added type::Story label

changed title from .NET Max Attachment Size to Max Attachment Size (.NET & JAVA SDKs)

changed the description

Bei Java ist es abhängig von der Laufzeitumgebung (daher hat es der Onlinedienst bzw. Fachverfahren in der Hand)
aktuell gibt es wohl im Zustelldienst auch zusätzlich einen Fehler bei größeren Dateien (bereits bei 700 MB) - diese Prüfung ist nicht Teil des Issues

Bei Java gibt es eine max. Größe von 2GB für Strings, diese lässt sich nicht konfigurativ erhöhen. Online-Dienst bzw. Fachverfahren können unterhalb dieser Grenze Einschränkungen haben (zu wenig Speicher, JVM-Konfiguration), dennoch stellen die 2GB eine harte Grenze dar (sofern mit Strings gearbeitet wird, was anscheined bei den eingesetzten Bibliotheken der Fall ist).
Die Grenzen des Zustelldienstes werden im Rahmen von #816 (closed) geprüft bzw. erweitert.

Ergebnisse Prüfung Java:

Ausgangslage:

2 GB File, Prüfung ob Encryption damit funktioniert.

Beobachtung:

Max heap Size der JVM (Xmx Parameter) wurde auf 14 GB (-Xmx14000m) gestellt, da es bei einem kleineren Wert direkt zu OutOfMemoryErrors kommt
Während der Base64Url Encodierung tritt eine NegativeArraySizeException auf

Caused by: java.lang.NegativeArraySizeException: -2057322642
	at com.nimbusds.jose.util.Base64Codec.encodeToString(Base64Codec.java:278)
	at com.nimbusds.jose.util.Base64URL.encode(Base64URL.java:99)
	at com.nimbusds.jose.crypto.impl.ContentCryptoProvider.encrypt(ContentCryptoProvider.java:238)
	at com.nimbusds.jose.crypto.RSAEncrypter.encrypt(RSAEncrypter.java:206)
	at com.nimbusds.jose.JWEObject.encrypt(JWEObject.java:375)

Ursache:

In Java haben (Byte)Arrays eine Größenbegrenzung von 2^31 Byte => 2,147,483,648 Byte
Der Overhead beim Encoden via Jose/Nimbus beträgt ca. den Faktor 1,36
Attachments aber einer Größe > 1.500 MB überschreiten diese Größe
ein Attachment von 1.500 MB erzeugt ein String von 2097792755 Byte der noch innerhalb dieser Grenze liegt

Schlussfolgerung:

Mit der eingesetzten Jose/Nimbus Library können ohne Einbau eines Chunkings, welches große Files in mehrere kleinere aufteilt, keine Attachments > 1,5 GB encrypted/encoded werden.

Danke Dir.

@Gerd_Aschemann @Marco_Holz @Hauke_Traulsen: FYI Damit haben wir auch für die Außenkommunikation eine relevante Einschränkung, die wir aufgreifen müssen.

Nach Rücksprache mit @Klaus_Fischer liegt die Grenze bei .NET jedoch eher <= 700 MB aus ähnlichen Gründen. Nach außen könnte man eine max. Größe von 500 MB kommunizieren bis wir eine Chunking Lösung gefunden haben die auch gut mit dem Zustelldienst harmonisiert.

Da ja in #816 (closed) zusätzlich ein Server Error kommt sollten wir vor der Kommunikation nach außen prüfen welche Einschränkungen der Zustelldienst (ohne Nutzung der SDKs) hat. Das ist auch bislang der Wert, den wir kommuniziert haben, ggf. passt es.

@Gerd_Aschemann: willst du dann sobald die Erkenntnisse aus #816 (closed) vorliegen ein Issue zur Lösung der Probleme aus Gesamtarchitektursicht anlegen?

Ansonsten wäre die Analyse mit dem Ergebnis (JAVA <1,5 GB; .NET <=700 MB) erstmal abgeschlossen.

Idee: wir könnten das Problem auf SDK-Seite umgehen, wenn wir mit ZIP-Stream arbeiten und die Attachments selbstständig "zerstückeln" und in kleinen Paketen verschlüsseln und hochladen.

Danke, finde ich auch cool. Was mir dazu einfällt: Es kann es ja immer passieren, dass ein Antrag aus dem SDK heraus gesendet wird, jedoch bei der Abholung kein SDK genutzt wird. Der Lösungsansatz müsste daher aus meiner Sicht vorher noch einmal integrativ bewertet werden.

Vielen Dank für deinen Hinweis, @Klaus_Fischer - hast du eine Quelle, was genau mit ZIP-Stream gemeint ist (sonst suche ich mal selbst) und kannst du gelegentlich deinen Ansatz kurz (mündlich) erklären?

Evtl. macht, neben einem ZipInputStream, auch die Evaluierung solcher Tools Sinn:

Können bzw. sollten wir denn Annahmen über den Komprimierungsstatus des Anhangs treffen? Wir können von uns aus nicht einfach eine übergebene Attachment-Datei nochmal komprimieren (mit egal welchem Tool oder Algorithmus): In der Regel vergrößert eine Komprimierung von bereits komprimierten Daten diese (oder lässt sie im besten Fall gleich, in jedem Fall ist Kompression aber eine starke CPU-Belastung), sog. "double compression"-Anomalie. Ich denke, wir sollten davon ausgehen, dass die Daten schon vom Sender komprimiert wurden bzw. wir müssen auch komprimierte (große) Attachments zuverlässig übermitteln.

Bevor wir aber hier Missverständnisse erzeugen, sollten wir einen Call ansetzen und die Optionen bzgl. ZIP-Streams (oder anderer Komprimierungen) besprechen.

Es muss ja nicht gezippt werden, es reicht ja wenn's zerhackt wird.

marked this issue as related to #816 (closed)

changed the description

added workflow::PO Review label and removed workflow::In Progress label

assigned to @Gerd_Aschemann and unassigned @Klaus_Fischer

changed milestone to %S-1 (PI-3)

Die Prüfung ist soweit abgeschlossen und Floss in das Issue #72 (closed) ein. Sobald sich Folgeaktivitäten für das SDK aus dem genannten Issue ergeben, sollte entsprechend ein neues Issue angelegt werden. Ich schließe in diesem Sinne dieses Issue.

closed

marked this issue as related to #72 (closed)

changed milestone to %PI-3 (Q-3)

added 1 deleted label

Max Attachment Size (.NET & JAVA SDKs)

Warum?

Research

Relevante Links und Bemerkungen

Akzeptanzkriterien

Next Steps

Designs

Child items ...

Activity