When reading the AARQ message, it seems that the server does not handle the MaxReceivePDUSize - it is simply ignored:
From GXAPDU.java: parseUserInformation()
if (settings.isServer()) {
data.getUInt16(); /* NTO: Server does not care about the MaxReceivePDUSize required by the Server ??!! */
} else {
settings.setMaxReceivePDUSize(data.getUInt16());
}
On the other hand, the client seems to split the received data into multiple DLMS objects to respect this behaviour - from the client point of view:
GXDLMSClient.java: readList()
// Request service primitive shall always fit in a single APDU.
int pos = 0, count = (settings.getMaxReceivePDUSize() - 12) / 10;
My questions are:
- Is my understanding correct ?
- Is there a way to force the server to send directly fragmented Cosem obects back to the client ?
It looks that forcing the MaxPduSize on the server side will only work when building LN messages, but is not used for SN ones.
Can you please confirm or infirm that the server is able to build Short Name multiblock messages ?
Use of the MaxReceivePDUSize Parameter
Hi,
Client can propose PDU size, but it's skipped at the moment and Server PDU size is used .
You can set PDU for server like this:
server.setMaxReceivePDUSize(62);
BR,
Mikko
Hello Mikko,
Hello Mikko,
Thanks for your reply.
It looks that forcing the MaxPduSize on the server side will only work when building LN messages, but is not used for SN ones.
Can you please confirm or infirm that the server is able to build Short Name multiblock messages ?
Thanks you