[hipl-dev] Re: [Merge] lp:~hipl-core/hipl/libhip into lp:hipl

  • From: Christof Mroz <christof.mroz@xxxxxxxxxxxxxx>
  • To: hipl-dev@xxxxxxxxxxxxx
  • Date: Fri, 17 Feb 2012 19:52:09 +0100

On 17.02.2012 17:49, Xin wrote:
On 14/02/12 22:34, Christof Mroz wrote:
+    fd_info_new = create_new_fd_info(new_fd, fd_info->bound_port,
+                                     fd_info->family, fd_info->proto);
+
+    if (hip_await_bex(fd_info_new, (struct sockaddr *)&ss)<   0) {
+        HIP_ERROR("Base exchange not successful.\n");
+        return -1;
+    }
+
+    if (new_peer_hit) {
+        phit = (struct sockaddr_in6 *) new_peer_hit;
+        memset(phit, 0, *hit_len);
+        memcpy(&phit->sin6_addr,&fd_info_new->ha->hit_peer,
+               sizeof(struct in6_addr));
+        phit->sin6_port = get_port_from_saddr((struct sockaddr *)&ss);
+        *hit_len        = sizeof(struct sockaddr_in6);
+    }
+
+    return new_fd;
+}
fd_info_new is not freed.

Those fd_infoS are maintained in a global list, so cannot be freed here.
the function hipl_close (previously hip_close) handle the case of free
fd_info.

OK, my bad

This test can verify both libhipl and hipnetcat. The hipnetcat cannot
act as client and server at the same time (like normal netcat), that's
why we have 2 processes.

Ah I see now. At first I thought that hipnetcast was written for the sole purpose of unit testing, and not conceived as a tool for distribution... If you want to test hipnetcat itself, the cleanest way would involve mock functions, both for the sender and listener case. But this would take some more effort that just forking of course. As I don't know about the auto builder internals and such, I will let others decide whether the fork() is acceptable.

In this case I don't see a need for the context management that I proposed anymore. Unless you think a library user might want to juggle multiple HIP sockets, and you don't want to rewrite anything so that it carries the static data inside the socket handle (which would be the cleanest solution, I guess).

Your advice gives me a good hint for the improvement of the libhipl API.
There are still many things to explore, and my graduation relies on it :)

Hopefully I helped rather than distracting you :) there are endless possibilities for tweaking an API.

Other related posts: