socket trapping

QNX Newsgroups (Archives) qdn.public.ddk.network
1

To trap socket i/o operation I can use new handler like below:
resmgr_attach(…,"/dev/socket/"DOMAIN_NUMBER, FTYPE_SOCK,_RESMGR_FLAG_BEFORE,…)
Q: how can I know which arguments were used with sendto() and recvfrom() calls and how I
can trap those calls at all and recv() and send() calls too ?

Vasili

2

In addition:
I tried:

memset( &resmgr_attr, 0, sizeof resmgr_attr );
resmgr_attr.nparts_max = 1;
resmgr_attr.msg_max_size = 2048;
iofunc_attr_init( &attr, S_IFSOCK | 0666, 0, 0 );
iofunc_func_init( _RESMGR_CONNECT_NFUNCS,
&connect_funcs, _RESMGR_IO_NFUNCS, &io_funcs );
connect_funcs.open = my_open;
…
io_funcs.read = my_io_read;
…
resmgr_attach(dpp, &resmgr_attr, DEV_SOCK_NAME,
_FTYPE_SOCKET,_RESMGR_FLAG_BEFORE,
&connect_funcs, &io_funcs, &attr);

while (1) {
if ( (ctp = resmgr_block( ctp )) == NULL ) {
return -1;
}
resmgr_handler(ctp);
}

In test prog was:
fd=socket(AF_INET,…)
etc

Q: Test worked OK, but my pre-processing open handler (and any other) did not get control
:frowning:(
Why ? Did I mistaken?

Vasili

3

I think you will find that resmgr’s match longest first. Since the tcp stack
is registering /dev/socket/2 and you are just doing /dev/socket, the kernel
is going to resolve to the tcp stack first. If you want to take over/filter
tcp operations then register /dev/socket/2 directly.

chris


vasa <vv40in@mail.ru> wrote:

In addition:
I tried:

memset( &resmgr_attr, 0, sizeof resmgr_attr );
resmgr_attr.nparts_max = 1;
resmgr_attr.msg_max_size = 2048;
iofunc_attr_init( &attr, S_IFSOCK | 0666, 0, 0 );
iofunc_func_init( _RESMGR_CONNECT_NFUNCS,
&connect_funcs, _RESMGR_IO_NFUNCS, &io_funcs );
connect_funcs.open = my_open;
…
io_funcs.read = my_io_read;
…
resmgr_attach(dpp, &resmgr_attr, DEV_SOCK_NAME,
_FTYPE_SOCKET,_RESMGR_FLAG_BEFORE,
&connect_funcs, &io_funcs, &attr);

while (1) {
if ( (ctp = resmgr_block( ctp )) == NULL ) {
return -1;
}
resmgr_handler(ctp);
}

In test prog was:
fd=socket(AF_INET,…)
etc

Q: Test worked OK, but my pre-processing open handler (and any other) did not ge
t control
:frowning:> (
Why ? Did I mistaken?

Vasili
\

–

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

4

Sorry, I found my little mistake before Your answer, Chris.

But now I have more questions:

  1. who is the way to call ORIGINAL handlers of i/o operations which I trap ?
    It is not only for _FTYPE_SOCKET.

General example (not for _FTYPE_SOCKET):
I register my handlers:
stat(“ANY/EXISTING/FILE/NAME”,&stat);
iofunc_attr_init( &attr, stat.st_mode, 0, 0 );
connect_funcs.open = my_open;
io_funcs.read = my_io_read;
io_funcs.stat = my_io_stat;
resmgr_attach(dpp, &resmgr_attr, “ANY/EXISTING/FILE/NAME”,
_FTYPE_ANY,_RESMGR_FLAG_BEFORE,
&connect_funcs, &io_funcs, &attr);

int my_io_stat(…){
// … some prosessing …
return iofunc_stat_default(…);
}

If client read stat information about “ANY/EXISTING/FILE/NAME” (for example ls -l
ANY/EXISTING/FILE/NAME) – my_io_stat handler gets control, but HOW can I call ORIGINAL
handler in this my_io_stat or after it ? In case if I return iofunc_stat_default() –
client gets wrong data about those “ANY/EXISTING/FILE/NAME”.
In case if I return 0 – the same. Why ? How do to call ORIGINAL handler ?


2. Explain me Your idea, please:

I think you will find that resmgr’s match longest first. Since the tcp stack
is registering /dev/socket/2 and you are just doing /dev/socket, the kernel
is going to resolve to the tcp stack first. If you want to take over/filter
tcp operations then register /dev/socket/2 directly.

What does it mean: If you want to take over/filter
tcp operations then register /dev/socket/2 directly. ?
I called:
resmgr_attach(dpp, &resmgr_attr, “/dev/socket/2”,
_FTYPE_SOCKET,_RESMGR_FLAG_BEFORE,
&connect_funcs, &io_funcs, &attr);
How can I register “/dev/socket/2” more direct than in this call ?

  1. What about context switching during socket IO operations processing in case of
    RESMGR_FLAG_BEFORE or RESMGR_FLAG_AFTER ?


    Thank You,
    Vasili


vasa <> vv40in@mail.ru> > wrote:

In addition:
I tried:

memset( &resmgr_attr, 0, sizeof resmgr_attr );
resmgr_attr.nparts_max = 1;
resmgr_attr.msg_max_size = 2048;
iofunc_attr_init( &attr, S_IFSOCK | 0666, 0, 0 );
iofunc_func_init( _RESMGR_CONNECT_NFUNCS,
&connect_funcs, _RESMGR_IO_NFUNCS, &io_funcs );
connect_funcs.open = my_open;
…
io_funcs.read = my_io_read;
…
resmgr_attach(dpp, &resmgr_attr, DEV_SOCK_NAME,
_FTYPE_SOCKET,_RESMGR_FLAG_BEFORE,
&connect_funcs, &io_funcs, &attr);

while (1) {
if ( (ctp = resmgr_block( ctp )) == NULL ) {
return -1;
}
resmgr_handler(ctp);
}

In test prog was:
fd=socket(AF_INET,…)
etc

Q: Test worked OK, but my pre-processing open handler (and any other) did not ge
t control
:frowning:> (
Why ? Did I mistaken?

Vasili



\

cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL

5

I belive that if you want to handle the actual I/O operations you are going
to have to keep an open connection to the interface you are taking over and
and re-call and return the results information. For example, if you took
over /dev/ser1 you would open( “/dev/ser1” ) and then keep that fd around
for use later when you wanted to read/write the “real” interface.

There is a different trick for dealing with open() but you can learn that
by looking at the libc source on cvs.qnx.com. :wink:

chris

–

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

6

vasa <vv40in@mail.ru> wrote:

Sorry, I found my little mistake before Your answer, Chris.

But now I have more questions:

  1. who is the way to call ORIGINAL handlers of i/o operations which I trap ?
    It is not only for _FTYPE_SOCKET.

General example (not for _FTYPE_SOCKET):
I register my handlers:
stat(“ANY/EXISTING/FILE/NAME”,&stat);
iofunc_attr_init( &attr, stat.st_mode, 0, 0 );
connect_funcs.open = my_open;
io_funcs.read = my_io_read;
io_funcs.stat = my_io_stat;
resmgr_attach(dpp, &resmgr_attr, “ANY/EXISTING/FILE/NAME”,
_FTYPE_ANY,_RESMGR_FLAG_BEFORE,
&connect_funcs, &io_funcs, &attr);

int my_io_stat(…){
// … some prosessing …
return iofunc_stat_default(…);
}

If client read stat information about “ANY/EXISTING/FILE/NAME” (for example ls -l
ANY/EXISTING/FILE/NAME) – my_io_stat handler gets control, but HOW can I call ORIGINAL
handler in this my_io_stat or after it ? In case if I return iofunc_stat_default() –
client gets wrong data about those “ANY/EXISTING/FILE/NAME”.
In case if I return 0 – the same. Why ? How do to call ORIGINAL handler ?

A state() call turns into “open/state/close” call. If you watch
it close, you should see both your open/state/close_ocb function
get called.

If you don’t want to handle tha call, you simply return ENOENT,
the client (who called stat()) will going on to talk to the next
server.

Take a look of how the magic is don in libc.

  1. Explain me Your idea, please:

I think you will find that resmgr’s match longest first. Since the tcp stack
is registering /dev/socket/2 and you are just doing /dev/socket, the kernel
is going to resolve to the tcp stack first. If you want to take over/filter
tcp operations then register /dev/socket/2 directly.

What does it mean: If you want to take over/filter
tcp operations then register /dev/socket/2 directly. ?
I called:
resmgr_attach(dpp, &resmgr_attr, “/dev/socket/2”,
_FTYPE_SOCKET,_RESMGR_FLAG_BEFORE,
&connect_funcs, &io_funcs, &attr);
How can I register “/dev/socket/2” more direct than in this call ?

If you attached /dev/sock/2 , then it’s OK I believe.

  1. What about context switching during socket IO operations processing in case of
    RESMGR_FLAG_BEFORE or RESMGR_FLAG_AFTER ?

Only the “socket()” call needs to find out the server, once it done,
the returned “fd” is actuallya coid to the server, so further call
write(fd, ) or recv(fd, ) will direct talk to the server without
look up.

-xtang

Thank You,
Vasili



vasa <> vv40in@mail.ru> > wrote:

In addition:
I tried:

memset( &resmgr_attr, 0, sizeof resmgr_attr );
resmgr_attr.nparts_max = 1;
resmgr_attr.msg_max_size = 2048;
iofunc_attr_init( &attr, S_IFSOCK | 0666, 0, 0 );
iofunc_func_init( _RESMGR_CONNECT_NFUNCS,
&connect_funcs, _RESMGR_IO_NFUNCS, &io_funcs );
connect_funcs.open = my_open;
…
io_funcs.read = my_io_read;
…
resmgr_attach(dpp, &resmgr_attr, DEV_SOCK_NAME,
_FTYPE_SOCKET,_RESMGR_FLAG_BEFORE,
&connect_funcs, &io_funcs, &attr);

while (1) {
if ( (ctp = resmgr_block( ctp )) == NULL ) {
return -1;
}
resmgr_handler(ctp);
}

In test prog was:
fd=socket(AF_INET,…)
etc

Q: Test worked OK, but my pre-processing open handler (and any other) did not ge
t control
:frowning:> (
Why ? Did I mistaken?

Vasili



\

cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL