* SCTP recvmsg MSG_TRUNC or something similar
@ 2019-07-24 13:46 Luci Stanescu
2019-07-25 1:21 ` Marcelo Ricardo Leitner
2019-07-25 9:53 ` Luci Stanescu
0 siblings, 2 replies; 3+ messages in thread
From: Luci Stanescu @ 2019-07-24 13:46 UTC (permalink / raw)
To: linux-sctp
Hi,
I’m not sure this is the right place to ask this kind of question, but, having not found a better forum, I’m trying my luck. Apologies in advance if this is outside the scope of the mailing list.
That being said, my question is: given a successful return of recvmsg() for a SOCK_SEQPACKET SCTP socket, is there no stateless way to determine if the read data, for which the MSG_EOR flag is set, is the trailing “fragment” of a larger record (either due to partial delivery or an insufficient buffer passed to a prior call to recvmsg() which returned with the MSG_EOR flag cleared), rather than a “full” message?
From what I can tell, MSG_TRUNC, which would’ve solved my issue, isn’t implemented for SCTP. Regarding this topic, I’ve only found old discussions, including some suggestions to add SOCK_RDM, which never materialised.
Many thanks for your time!
Luci
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: SCTP recvmsg MSG_TRUNC or something similar
2019-07-24 13:46 SCTP recvmsg MSG_TRUNC or something similar Luci Stanescu
@ 2019-07-25 1:21 ` Marcelo Ricardo Leitner
2019-07-25 9:53 ` Luci Stanescu
1 sibling, 0 replies; 3+ messages in thread
From: Marcelo Ricardo Leitner @ 2019-07-25 1:21 UTC (permalink / raw)
To: linux-sctp
On Wed, Jul 24, 2019 at 02:46:09PM +0100, Luci Stanescu wrote:
> Hi,
Hi,
>
> I’m not sure this is the right place to ask this kind of question,
> but, having not found a better forum, I’m trying my luck. Apologies
Considering you're programming for Linux, it is. :-)
> in advance if this is outside the scope of the mailing list.
>
> That being said, my question is: given a successful return of
> recvmsg() for a SOCK_SEQPACKET SCTP socket, is there no stateless
> way to determine if the read data, for which the MSG_EOR flag is
> set, is the trailing “fragment” of a larger record (either due to
> partial delivery or an insufficient buffer passed to a prior call to
> recvmsg() which returned with the MSG_EOR flag cleared), rather than
> a “full” message?
Stateless, I'm not aware of a way.
We do have SCTP_PARTIAL_DELIVERY_EVENT, though, and RCVINFO. But these
would require some state to be preserved.
MSG_PEEK also, but also requires some state.
>
> From what I can tell, MSG_TRUNC, which would’ve solved my issue,
> isn’t implemented for SCTP. Regarding this topic, I’ve only found
Agreed, but MSG_TRUNC would cause information loss.
What about using a larger buf?
> old discussions, including some suggestions to add SOCK_RDM, which
> never materialised.
>
> Many thanks for your time!
>
> Luci
Regards,
Marcelo
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: SCTP recvmsg MSG_TRUNC or something similar
2019-07-24 13:46 SCTP recvmsg MSG_TRUNC or something similar Luci Stanescu
2019-07-25 1:21 ` Marcelo Ricardo Leitner
@ 2019-07-25 9:53 ` Luci Stanescu
1 sibling, 0 replies; 3+ messages in thread
From: Luci Stanescu @ 2019-07-25 9:53 UTC (permalink / raw)
To: linux-sctp
Hi Marcelo,
Many thanks for getting back to me!
> On 25 Jul 2019, at 02:21, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote:
>>
>> From what I can tell, MSG_TRUNC, which would’ve solved my issue,
>> isn’t implemented for SCTP. Regarding this topic, I’ve only found
>
> Agreed, but MSG_TRUNC would cause information loss.
In my particular context, of using SCTP as a transport for an internal, “proprietary” protocol, I know how large messages can be and my only intention is to efficiently discard messages which are deemed too large (why these messages would exist within a controlled environment in the first place is beyond the scope of this discussion).
Which means that, given a sufficient buffer, and, for the time being, ignoring partial deliveries, I’m comfortable discarding recvmsg() returns which don’t have MSG_EOR set; but I am still stuck with the trailing data and I would need to determine based on previous reads that this is not a complete message – a flag that signifies “start-of-record” would have been brilliant. Or I can simply process them as if they were a complete message and hope they’re not validly formed.
> What about using a larger buf?
But, how large? :-)
Cheers,
Luci
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-07-25 9:53 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-24 13:46 SCTP recvmsg MSG_TRUNC or something similar Luci Stanescu
2019-07-25 1:21 ` Marcelo Ricardo Leitner
2019-07-25 9:53 ` Luci Stanescu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.