Hello,
Svante Signell, le Fri 10 Apr 2015 13:58:23 +0200, a écrit :
> New test programs:
> auth_socket_send/recv.c
> ident_socket_send/recv.c (change if 0 to if 1 to activate
> proc_user/server_identify())
They look fine. There is just one thing: AIUI, on the sender side,
instead of inserting a send right and then using
MACH_MSG_TYPE_COPY_SEND, you could just use MACH_MSG_TYPE_MAKE_SEND
> One strange thing with these programs (without
> proc_user/server_identify() enabled) is:
> - auth_socket_send/recv.c reports received data being zero for
> SOCKET_STREAM
> - ident_socket_send/recv.c reports received data being zero for
> SOCKET_DGRAM
Errr, no, in my tests the two programs have the same behavior in stream
and dgram case. I would be extremely surprised if the two program had
different behavior since they're basically exactly the same apart from
the variable names. I wouldn't have been surprised that stream not
support passing ports, but it seems to actually be implemented, which is
good :)
So passing the rendezvous port seems to be working fine:
ident_socket_recv.c: p_pid = 1240
ident_socket_recv.c: Socket file descriptor = 3
ident_socket_recv.c: Receiving via datagram socket
ident_socket_recv.c: __socket_recv() returned 30 bytes
ident_socket_recv.c: Received data = 0
ident_socket_recv.c: rendezvous port = 56
ident_socket_send.c: Socket file descriptor = 3
ident_socket_send.c: Sending via datagram socket
ident_socket_send.c: rendezvous port = 54
ident_socket_send.c: Sent p_pid = 1241
ident_socket_send.c: Sent data = 12345
ident_socket_send.c: __socket_send() returned 30 bytes
and with an extra pause() before the proc_user/server_identify call:
# portinfo -t 1240 1241
...
54 => 56: send
i.e. port 54 in the sender (1241) properly appeared as port
56 in the receiver (1240). Now you need to check that the
proc_user/server_identify RPC properly passes ports to the proc server
so that the port name gets the same there.
Samuel
