Missing coap max ack timeout in Coapconfig.java applydefinitions

[sathysreenath]

It looks like the coap max ack timeout parameter is missing from this file, hence when we generate the californium properties we do not see this parameter as well. So we cannot adjust the max ack timeout to a value other than 60 seconds. I see that the max ack timeout is declared as public static param in the file.

californium/californium-core/src/main/java/org/eclipse/californium/core/config/CoapConfig.java

Lines 794 to 852 in e927def

	@Override
	public void applyDefinitions(Configuration config) {
	final int CORES = Runtime.getRuntime().availableProcessors();
	config.set(MAX_ACTIVE_PEERS, DEFAULT_MAX_ACTIVE_PEERS);
	config.set(MAX_PEER_INACTIVITY_PERIOD, DEFAULT_MAX_PEER_INACTIVITY_PERIOD_IN_SECONDS, TimeUnit.SECONDS);
	config.set(COAP_PORT, CoAP.DEFAULT_COAP_PORT);
	config.set(COAP_SECURE_PORT, CoAP.DEFAULT_COAP_SECURE_PORT);
	config.set(ACK_TIMEOUT, 2000, TimeUnit.MILLISECONDS);
	config.set(ACK_INIT_RANDOM, 1.5f);
	config.set(ACK_TIMEOUT_SCALE, 2f);
	config.set(MAX_RETRANSMIT, 4);
	config.set(EXCHANGE_LIFETIME, DEFAULT_EXCHANGE_LIFETIME_IN_SECONDS, TimeUnit.SECONDS);
	config.set(NON_LIFETIME, 145, TimeUnit.SECONDS);
	config.set(NSTART, 1);
	config.set(LEISURE, 5, TimeUnit.SECONDS);
	config.set(PROBING_RATE, 1f);
	config.set(USE_MESSAGE_OFFLOADING, false);
	config.set(MAX_LATENCY, 100, TimeUnit.SECONDS);
	config.set(MAX_TRANSMIT_WAIT, 93, TimeUnit.SECONDS);
	config.set(MAX_SERVER_RESPONSE_DELAY, 250, TimeUnit.SECONDS);
	config.set(USE_RANDOM_MID_START, true);
	config.set(MID_TRACKER, DEFAULT_MID_TRACKER);
	config.set(MID_TRACKER_GROUPS, DEFAULT_MID_TRACKER_GROUPS);
	config.set(TOKEN_SIZE_LIMIT, 8);
	config.set(PREFERRED_BLOCK_SIZE, DEFAULT_PREFERRED_BLOCK_SIZE);
	config.set(MAX_MESSAGE_SIZE, DEFAULT_MAX_MESSAGE_SIZE);
	config.set(MAX_RESOURCE_BODY_SIZE, DEFAULT_MAX_RESOURCE_BODY_SIZE);
	config.set(BLOCKWISE_STATUS_LIFETIME, DEFAULT_BLOCKWISE_STATUS_LIFETIME_IN_SECONDS, TimeUnit.SECONDS);
	config.set(BLOCKWISE_STATUS_INTERVAL, DEFAULT_BLOCKWISE_STATUS_INTERVAL_IN_SECONDS, TimeUnit.SECONDS);
	config.set(BLOCKWISE_STRICT_BLOCK2_OPTION, DEFAULT_BLOCKWISE_STRICT_BLOCK2_OPTION);
	config.set(BLOCKWISE_ENTITY_TOO_LARGE_AUTO_FAILOVER, DEFAULT_BLOCKWISE_ENTITY_TOO_LARGE_AUTO_FAILOVER);
	config.set(BLOCKWISE_REUSE_TOKEN, false);
	// BERT enabled, when > 1
	config.set(TCP_NUMBER_OF_BULK_BLOCKS, 4);
	config.set(NOTIFICATION_CHECK_INTERVAL_TIME, 120, TimeUnit.SECONDS);
	config.set(NOTIFICATION_CHECK_INTERVAL_COUNT, 100);
	config.set(NOTIFICATION_REREGISTRATION_BACKOFF, 2000, TimeUnit.MILLISECONDS);
	config.set(CONGESTION_CONTROL_ALGORITHM, CongestionControlMode.NULL);
	config.set(PROTOCOL_STAGE_THREAD_COUNT, CORES);
	config.set(DEDUPLICATOR, DEFAULT_DEDUPLICATOR);
	config.set(MARK_AND_SWEEP_INTERVAL, DEFAULT_MARK_AND_SWEEP_INTERVAL_IN_SECONDS, TimeUnit.SECONDS);
	config.set(PEERS_MARK_AND_SWEEP_MESSAGES, DEFAULT_PEERS_MARK_AND_SWEEP_MESSAGES);
	config.set(CROP_ROTATION_PERIOD, DEFAULT_CROP_ROTATION_PERIOD_IN_SECONDS, TimeUnit.SECONDS);
	config.set(DEDUPLICATOR_AUTO_REPLACE, DEFAULT_DEDUPLICATOR_AUTO_REPLACE);
	config.set(RESPONSE_MATCHING, DEFAULT_RESPONSE_MATCHING);
	config.set(MULTICAST_BASE_MID, DEFAULT_MULTICAST_BASE_MID);
	config.set(STRICT_EMPTY_MESSAGE_FORMAT, true);
	config.set(MAX_SERVER_OBSERVES, DEFAULT_MAX_SERVER_OBSERVES);

public void applyDefinitions(Configuration config) {...}

I see a ack timeout but no max ack timeout.

[boaks]

Yes, good catch, I will add it.

[sbernard31]

Just by curiosity, is there plan to release a new version with this fix ?

[boaks]

I'm busy with other jobs, but I will try that for Thursday 20.07.2023.

[sbernard31]

I do not want to trigger a release, but just know if there was something planned. So I could decide if this could be integrated in Leshan 2.0.0-M12.

So don't release because of this question.

[boaks]

So don't release because of this question.

No, not just because of the question.
I had that in mind, but I'm currently on something else. The 20.07.2023 should be OK for me.
AFAIK, there may be some OSCORE bugfixes pending, but I'm not sure, what's the schedule there.

[sbernard31]

AFAIK, there may be some OSCORE bugfixes pending, but I'm not sure, what's the schedule there.

I didn't get news from @rikard-sics since a long time, I don't know if it still plan to move OSCORE forward on Leshan/Californium.
On your side, this is still not something you plan to work on ? (This is just to be able to answer to Leshan Community question)

[boaks]

On your side, this is still not something you plan to work on ?

I currently spend my most time into cellular apps and plan to spend time into the CoAP-S3-proxy afterwards.
I don't plan to spend time in OSCORE, DTLS 1.3, execution- or config-redesign.
The "goal" from my side is somethings as spending "1 afternoon per week" into Californium and tinydtls.

Beside of Julian's request, it's hard to see, if someone else is really interested in changes.
At least, I don't see someone, who is willing to spend time in that.