DATAGRAM Socket and UDP header

I have an application that performs a read operation from a UDP socket.
But the problem is that the length of the embedded data is not known to me
before hand. Nor is this value stored in the payload header of the
embedded packet. The only place were I can get this information is from
the UDP or IP header. And the datagram socket lets the application read
only the payload and not the header.

Raw socket can also not help here as what i am trying to receive is a UDP
packet from a test set and the kernel will never forward data with IP
protocol type set to UDP, to a raw socket. Raw socket can only receive
some user defined protocol types and ICMP/IGMP kind of frames.

So, I am trying to figure out how could I read the UDP header in a
situation like this

Thanks,

Tanmay.

The length of the data portion of the packet is the
return value of the read().

-seanb

Tanmay Kishore <tkishore@ditechcom.com> wrote:

I have an application that performs a read operation from a UDP socket.
But the problem is that the length of the embedded data is not known to me
before hand. Nor is this value stored in the payload header of the
embedded packet. The only place were I can get this information is from
the UDP or IP header. And the datagram socket lets the application read
only the payload and not the header.

Raw socket can also not help here as what i am trying to receive is a UDP
packet from a test set and the kernel will never forward data with IP
protocol type set to UDP, to a raw socket. Raw socket can only receive
some user defined protocol types and ICMP/IGMP kind of frames.

So, I am trying to figure out how could I read the UDP header in a
situation like this

Thanks,

Tanmay.

Sean Boudreau <seanb@qnx.com> wrote:

The length of the data portion of the packet is the
return value of the read().

Wouldn’t the return from the read lesser of the data portion
and the number of bytes requested by the read? Or would reading
for less than the size of the UDP packet be an error?

-David


-seanb

Tanmay Kishore <> tkishore@ditechcom.com> > wrote:
I have an application that performs a read operation from a UDP socket.
But the problem is that the length of the embedded data is not known to me
before hand. Nor is this value stored in the payload header of the
embedded packet. The only place were I can get this information is from
the UDP or IP header. And the datagram socket lets the application read
only the payload and not the header.

Raw socket can also not help here as what i am trying to receive is a UDP
packet from a test set and the kernel will never forward data with IP
protocol type set to UDP, to a raw socket. Raw socket can only receive
some user defined protocol types and ICMP/IGMP kind of frames.

So, I am trying to figure out how could I read the UDP header in a
situation like this

Thanks,

Tanmay.


David Gibbs
QNX Training Services
dagibbs@qnx.com

but remember that read might not be able to read the complete datagram
everytime. there are situations were this can happen and have been well
documented in the QNX library reference for read. So, in situation were
you encounter partial reads, how do you figure out how much more is left
for that frame.

Tanmay.


Sean Boudreau wrote:


The length of the data portion of the packet is the
return value of the read().

-seanb

Tanmay Kishore <> tkishore@ditechcom.com> > wrote:
I have an application that performs a read operation from a UDP socket.
But the problem is that the length of the embedded data is not known to me
before hand. Nor is this value stored in the payload header of the
embedded packet. The only place were I can get this information is from
the UDP or IP header. And the datagram socket lets the application read
only the payload and not the header.

Raw socket can also not help here as what i am trying to receive is a UDP
packet from a test set and the kernel will never forward data with IP
protocol type set to UDP, to a raw socket. Raw socket can only receive
some user defined protocol types and ICMP/IGMP kind of frames.

So, I am trying to figure out how could I read the UDP header in a
situation like this

Thanks,

Tanmay.

I think you may be worying about SOCK_STREAM semantics.

For SOCK_DGRAM, the stack won’t unblock the read until the
entire packet is available. Presumeably you know what the
max size of the data should be so none will be lost. If you
happen to have underalloc’d your read buffer, and you’re
using recvmsg(), the MSG_TRUNC flag will be set as an indication
but the difference of the packet will be lost.

-seanb

Tanmay Kishore <tkishore@ditechcom.com> wrote:

but remember that read might not be able to read the complete datagram
everytime. there are situations were this can happen and have been well
documented in the QNX library reference for read. So, in situation were
you encounter partial reads, how do you figure out how much more is left
for that frame.

Tanmay.



Sean Boudreau wrote:



The length of the data portion of the packet is the
return value of the read().

-seanb

Tanmay Kishore <> tkishore@ditechcom.com> > wrote:
I have an application that performs a read operation from a UDP socket.
But the problem is that the length of the embedded data is not known to me
before hand. Nor is this value stored in the payload header of the
embedded packet. The only place were I can get this information is from
the UDP or IP header. And the datagram socket lets the application read
only the payload and not the header.

Raw socket can also not help here as what i am trying to receive is a UDP
packet from a test set and the kernel will never forward data with IP
protocol type set to UDP, to a raw socket. Raw socket can only receive
some user defined protocol types and ICMP/IGMP kind of frames.

So, I am trying to figure out how could I read the UDP header in a
situation like this

Thanks,

Tanmay.

David Gibbs <dagibbs@qnx.com> wrote:

Sean Boudreau <> seanb@qnx.com> > wrote:

The length of the data portion of the packet is the
return value of the read().

-seanb

Wouldn’t the return from the read lesser of the data portion
and the number of bytes requested by the read?

???

Or would reading
for less than the size of the UDP packet be an error?

-David

The stack doesn’t consider it an ‘error’, although it
probaly is at any higher level protocol based on UDP.
The stack will set the MSG_TRUNC flag to recvmsg() as
an indication and return out what it could.

-seanb



Tanmay Kishore <> tkishore@ditechcom.com> > wrote:
I have an application that performs a read operation from a UDP socket.
But the problem is that the length of the embedded data is not known to me
before hand. Nor is this value stored in the payload header of the
embedded packet. The only place were I can get this information is from
the UDP or IP header. And the datagram socket lets the application read
only the payload and not the header.

Raw socket can also not help here as what i am trying to receive is a UDP
packet from a test set and the kernel will never forward data with IP
protocol type set to UDP, to a raw socket. Raw socket can only receive
some user defined protocol types and ICMP/IGMP kind of frames.

So, I am trying to figure out how could I read the UDP header in a
situation like this

Thanks,

Tanmay.


David Gibbs
QNX Training Services
dagibbs@qnx.com

Sean Boudreau <seanb@qnx.com> wrote:

I think you may be worying about SOCK_STREAM semantics.

For SOCK_DGRAM, the stack won’t unblock the read until the
entire packet is available. Presumeably you know what the
max size of the data should be so none will be lost. If you
happen to have underalloc’d your read buffer, and you’re
using recvmsg(), the MSG_TRUNC flag will be set as an indication
but the difference of the packet will be lost.

…lost if you’re not using MSG_PEEK.

-seanb

Tanmay Kishore <> tkishore@ditechcom.com> > wrote:
but remember that read might not be able to read the complete datagram
everytime. there are situations were this can happen and have been well
documented in the QNX library reference for read. So, in situation were
you encounter partial reads, how do you figure out how much more is left
for that frame.

Tanmay.



Sean Boudreau wrote:



The length of the data portion of the packet is the
return value of the read().

-seanb

Tanmay Kishore <> tkishore@ditechcom.com> > wrote:
I have an application that performs a read operation from a UDP socket.
But the problem is that the length of the embedded data is not known to me
before hand. Nor is this value stored in the payload header of the
embedded packet. The only place were I can get this information is from
the UDP or IP header. And the datagram socket lets the application read
only the payload and not the header.

Raw socket can also not help here as what i am trying to receive is a UDP
packet from a test set and the kernel will never forward data with IP
protocol type set to UDP, to a raw socket. Raw socket can only receive
some user defined protocol types and ICMP/IGMP kind of frames.

So, I am trying to figure out how could I read the UDP header in a
situation like this

Thanks,

Tanmay.

Sean Boudreau <seanb@qnx.com> wrote:

David Gibbs <> dagibbs@qnx.com> > wrote:
Sean Boudreau <> seanb@qnx.com> > wrote:

The length of the data portion of the packet is the
return value of the read().

-seanb

Wouldn’t the return from the read lesser of the data portion
and the number of bytes requested by the read?

???

Packet has 400 bytes of data.

I call read( udp_fd, buf, 200 )

Return should be 200, right?

Whereas you said it would be 400 – the length of the data portion
of the packet.

(Or, make it recvfrom( udp_socket, buf, 200, 0, NULL, 0 ).)

Return of read/recvfrom is min( data avail, buffer size specified ).

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

Sorry for the quite late reply… I read this forum very rarely…

  • One thing to know about UDP packets is that they are limited by the
    very nature of UDP: max size is about 64 KBytes. If you try to read
    64 KBytes, then the result from the read should always be less than
    64 KBytes, and the result code should be the read data bytes length.
    This does give you an a-priori value for the data you can expect. NB:
    should the sender do a ‘broadcast’ (to address 255.255.255.255 for
    example) then the max packet size is even more limited, but i have
    found that to be a ‘typical’ QNX (6.1 … 6.3) interpretation of the
    UDP standard: QNX limits the packet size to one MTU of the network
    (~1500 bytes for LAN).

  • another thing: UDP has no ‘queue’ (in the sense that TCP has one).
    UDP is packet oriented, and you should only get the ‘latest packet’.
    What QNX interpretes as ‘latest packet’ is implementation dependent
    (Linux/QNX/windows all have their own interpretation of what UDP is
    supposed to do here). This implies that should two packets have been
    sent before the receiver does a read, then the first packet may go
    ‘lost’ → not be sent to the receiving program at all. This is no
    error, it’s just how UDP is supposed to work.

prfaasse wrote:

Sorry for the quite late reply… I read this forum very rarely…

The section of openqnx listed as “QNX Newsgroups” is not a forum as such. You happen to be using a website as a news reader. I recommend you connect directly using a full featured reader, the server url to connect to is nntp://inn.qnx.com


Evan