Questions about network_macros [ was: Re: more ptal_t (strict) ]

[Ivan Gyurdiev]

> There should be 9 that are used
> can_network (Allow all network activity)
> can_network_server  (tcp and udp, requires a name_bind)
> can_network_client   (tcp and udp, requires a name_connect)
> can_network_client_udp (udp requires)
> can_network_client_tcp (tcp requires a name_connect)
> can_network_server_udp (udp requires a name_bind)
> can_network_server_tcp (tcp requires a name_bind)
> can_network_tcp (tcp requires a name_connect and a name_bind)
> can_network_udp (udp requires a name_bind)
> 
> The other port type parameter can be used to "lock down" udp connects 
> since name_connect does not work for udp.

So why don't we add name_connect and name_bind to the macros 
where required.

> I don't recall why, but name_connect was added the way it was because 
> name_bind was done that way. 

...

> Also passing a lot of parameters in macros is somewhat frowned on, since 
> it complicates the code quite
> a bit.  It was decided to break these functions in to multiple function 
> calls.

I don't argue with the breaking of calls - that seems like a good idea,
but if you say name_bind and name_connect are required in certain
scenarios, then we should probably add those to the networking macros.

For example, the port_type argument in base_can_macros could be used for
name_connect, not only for send_msg/rcv_msg. For name_bind I guess you'd
need another argument, since servers should be able to send/receive to
all ports (actually - should this be all unrestristed ports?)


> >Basically I've been writing:
> >
> >can_network_client(domain)
> >allow domain specific_port:tcp_socket/udp_socket name_connect;
> >
> >can_network_server(domain)
> >allow domain specific_port:tcp_socket/udp_socket name_bind;

 I'm thinking something like:

- include name_bind and name_connect where appropriate
- require socket_type (but only if udp/tcp not specified)
- include port_type in server for the port that server can bind to

(maybe require port_type too - why is all of this optional
if you want to enforce stricter policy?)

can_network_client(domain, socket_type, (, port_type)?);
can_network_client_(tcp|udp) (domain (,port_type)?);

socket_type - type of socket over which to communicate
port_type - server port the client is authorized to talk to

can_network_server(domain, socket_type, (, port_type)?);
can_network_server_(tcp_udp) (domain (,port_type)?);

socket_type - type of socket over which to communicate
port_type - server port the server is authorized to bind to/listen on
(it can connect to all unrestricted ports (but not name_connect?));

or something like that...

Then instead of calling can_resolve:

can_network_client_udp(domain, dns_port_t) or
can_network_client(domain, udp_socket, dns_port_t)

Instead of can_ldap:

can_network_client_tcp(domain, ldap_port_t) or
can_network_client(domain, tcp_socket, ldap_port_t)

-- 
Ivan Gyurdiev <ivg2 at cornell.edu>
Cornell University