> However, EPOC Socket API does not have recvmsg equivalent, and I still have
> the problem I presented with whatever solution I invent (ioctl?) for
> retrieving the packet data. But, that will be local issue of no generic
> insterest.
I think inventing a mechanism which delivers ancillary data (or the equivalent
thereof) together with the data is the best way to go.
A getsockopt() would need to somehow indicate which packet you want
the ancillary data for.
Otherwise, things would be confusing e.g. in this case
t=0 packet 1 from A with routing header X arrives. Queued in the socket
queue.
t=1 packet 2 from B with routing header Y arrives. Queued in the socket
queue.
t=10 application calls recv() to get data
t=11 application calls getsockopt to get ancillary data (routing header)
Does this retrive X or Y?
t=100 application calls recv() to get data
t=101 packet 3 from C with routing header Z arrives. Queued in the socket
queue.
t=101 application calls getsockopt to get ancillary data (routing header)
Does this retrive Z?
Does the getsockopt retrieve from the most recently received packet?
Note that the socket API had the above problem for IPv4 using
getsockopt(IP_OPTIONS) to retrieve information from UDP/IP.
This was fixed by assing IP_RECVOPTS which is delivered using
ancillary data.
Erik
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
