A little more info:
- When i have MTU > 16K, no problem, 1 notification makes it through
with an EOR and proper info
EOR.
- ssf_flags are always zero (thats one other place that may have carried
such extra info)
- kernel 3.12.0 (with other non-sctp patches)
cheers,
jamal
On 12/18/13 08:59, Jamal Hadi Salim wrote:
Lets say between server and client i have an MTU of 4K.
I send 16K with partial reliability setting.
If the data gets through the receiver sees (I think
SCTP_PARTIAL_DELIVERY_POINT may change this behavior but it probably
defaults to MTU):
Msg1, 4k, !EOR
Msg2, 4k, !EOR
Msg3, 4k, !EOR
Msg4, 4k, EOR
OTOH, at sender if the send fails because PR timeout on some data
chunk occurs i receive from the kernel not 1 but 4 notifications.
Msg1, 4k, Notification(send failed, ssf_length=4k), EOR
Msg2, 4k, Notification(send failed, ssf_length=4k), EOR
Msg3, 4k, Notification(send failed, ssf_length=4k), EOR
Msg4, 4k, Notification(send failed, ssf_length=4k), EOR
.... some last message here to account for notification overhead ....
I was expecting only the last one to have an EOR or least the
ssf_length to be telling me there's more than 4K. Stoopid question:
Is there some other field I should be looking at?
The only way i could tell the 5 notifications are from the same
original message is when i provide a sinfo_context at sendmsg() time.
cheers,
jamal
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
