Negotiating Bluetooth LE ATT MTU on Android and iOS central / peripheral in practice

Question

On Android we have requestMtu and onMtuChanged, which seems to imply that we have to manually negotiate MTU sizes, if both central and peripheral devices are Android based (but I might be wrong and it might be that it happens also automatically upon connection without my intervention). Documentation for requestMtu talks only about write request (write without response) operation and does not mention notifications, and also says that it is meant for "connection" but does not mention if it's from central or peripheral side. Thus, it's not clear, which side of the connection can/should use requestMtu and how it affects both notification size and write size?

On iOS, it seems, there is no direct alternative to requestMtu and we have only central.maximumUpdateValueLength (since iOS 7, I guess). Its documentation (on the contrary to the Android one) says that maximumUpdateValueLength is for notification updates only, which implies that it is useful only on the peripheral side, since you send notifications from peripheral to central. But what about writes? If I'm writing (again without response) to a characteristic from a central to a peripheral, how do I know my batch size to ensure efficient writes?

Considering mixed systems (Android/iOS central/peripheral), it all gets confusing and it is not clear at all which side and when can/should request/react to MTU size negotiation. Is there any document describing ATT MTU exchange options, which correspond to real Android and iOS implementation?

Answer 1

Asper my understanding requestMtu() should be initiated from central role device as it knows how much data it is going to transmit n receive. In general, in any client server model it is always the client that tells or negotiates the session parameters. Hence I feel even in the case of BLE the same rule fits.