Progress Report

2/17/99

    Here is the situation with the class view group.

  • Here is what we do know:
      The JNI is defined as two parts. The Java code and the C code in the client (comm_native.c). The Java code calls the C code, the C code calls the necessary functions inside the client. I hope to show that:
      1. the Java code and C code parts of the JNI are, in fact, working.
      2. The problems (as listed by Nick below) are all a result of client problems

      If I can prove these two things, then I have shown the need for the help of people outside of our group (since the scope of Class View is the JNI and *not* the client code).

      Is the Java code working? Yes. The Java code compiles, and when the Java code is run we see that (by using printf statements) it is indeed calling the appropriate functions in comm_native.c

      Is comm_native.c working? Yes. Here is an example of the function that creates an agent in comm_native.c: 

      	if(!comm_CreateAgent(comm, 0))
           printf("Unable to create agent...\n");
        else
	   printf("Got back from creating agent successfully...\n");
	while(def == 0)
		while(comm_HandleEvent(comm));
	}
	def = 0;
	return(agent_id);
      Notice there is really only two things going on here. First we call comm_CreateAgent (which is a function in the client and not the JNI). Second we call comm_HandleEvent (which is same as before).

      Yeah, but is this code really working? Yes. When comm_native creates an agent, the server acknowledges the creation of the agent.

      Since the Java code works and the comm_native's only job is to call other functions in the client, the only possible explanation for the problems are:

      1. We are calling the client functions incorrectly in comm_native
      2. The client code is buggy
      If situation 1 is true, then that would be pointed out by someone outside of the group (with some expertise in the client) very quickly (I would assume, anyways). If situation 2 is true, then we need to work with the group, whose responsibility it is to govern the client code, to fix those problems in an efficient manner.

      Either way, the Class View group is at an impasse that cannot be resolved until someone from the client group(?) spends some quality time with us.

      But Ryan, if you've known about this then why haven't you contacted other groups about it? Well, you guys should have attended last week's meeting when I asked for "quality time" from the networking people.

      They recommended that I talk to Kevin, since the two networking people know nothing about the NT code. Kevin has been sick lately (and wasn't at the meeting) I sent him an email requesting help. I have gotten no reply. On Monday I sent out another email to Kevin and one to Stephen. I have spoken with Stephen, since then; he is too busy working to look at it now and NT is not his expertise, but will notify me if he finds out anything while porting the client to Solaris. I have gotten no replies as of yet. (I also sent joel the info yesterday)

      It is my belief that knowledge of the NT code is not a prerequisite to understanding the client.


  • The Problems and Problem Owners:
    1. Agents do not appear in the viewer even though they connect and register with the server.
        We may be calling the create agent code incorrectly (even though it is the exact same as the viewer code -- which does work). I need to sit down with someone who knows the viewer real well and figure this out. I own some stock in this problem, but it is not clear at this point who to blame. I have been aware of this problem for a week and half.

    2. The network queues overflows eventually/occasionally.
        This is completely out of the league of the Class View Team. We do not own this at all. This falls into the networking area.

    3. The client starts having problems sending packets.
        It is possible that we are calling something wrong, but not likely. This falls into the Networking area.

    4. The client gets an incessant network receive error messages which tell us no error. 
        Network Receive Error (0): No Error
        This has to do with UDP, line 444 in network.c. I mentioned this in the VRM meeting 3 weeks ago.

      3 out of 4 of our problems require networking people. The first, requires someone with knowledge of the viewer/client.

      As previously mentioned, if my diagnosis of the problem is incorrect, then that would be pointed out by someone with some expertise in the client very quickly. Which is why I've been asking for help for the last week.

    << Back to Course View: Winter 1999