? 2008?11?12? 14:49, Erik Nordmark ??: > James Carlson wrote: > >> The situation for UDP is a bit different. Since there is no real >> connection in UDP and the same socket can be used to send to >> multiple destinations, the major task is to register the five-tuple >> at the cluster level. Such registration is performed at connect(), >> sendto() and sendmsg(), which call the cl_inet_connect() hook at >> proper time. For performance reasons, sendto()/sendmsg() calls the >> hook only when the destination is new. To facilitate this, two new >> fields are added to the udp_t struct to store the most recent >> destination address and port: in6_addr_t udp_cl_v6lastdst; in_port_t >> udp_cl_lastdstport; In a sendto() or sendmsg(), the >> cl_inet_connect() hook is called only when the destination is >> different from most recent one.
[ cc Honsing from the Cluster team.] Hi Erik, Thanks for reviewing it. > Since UDP currently does not call cl_inet_connect, I assume the above > paragraph refers to the proposed new behavior. Yes, for the new behavior. > > Does the reference to sendmsg/sendto imply that this will be implemented > in sockfs? Or will it be implemented in TCP? When sendmsg/sendto are called from an application, the registrations are finally implemented in udp_wput(). You can refer to the webrev at http://greatwall.prc/~hl157128/tmp.cluster/webrev.stonedog.1111/ > > I don't understand why a new udp_cl_v6lastdst is needed since udp > already has a udp_v6lastdst field. The udp_v6lastdst field is used for Trusted Extension. To be safe, I don't want to reuse it, so the two new fields are introduced. > > > Is the intent that Cluster be useful with exclusive-IP zones in the future? > If so it might make sense to take this opportunity to introduce an > instance identifier to the function signatures. The requirement for this project (RFE 6717519) comes from a customer (Siemens). Using Cluster with exclusive zones is not in the requirement. I don't know if this will happen in the future. Honsing is from the Cluster team, so he may provide such information. Thanks. -- Huafeng > > Erik >
