Re: Piggyback message support

On Wed, 2003-04-16 at 02:07, Tunnel Team wrote:
> Our team is nearing completion of our Tunnel implementation (code will be
> available soon on sourceforge once we can get our CVS repository
> transfered.)

great!
> 
> I'm working on adding piggybacking support to the profile for standards
> compliance and to aid in testing with our beepcore-java version of the
> profile. As I see it, there are 4 areas where piggybacked messages need to
> be taken care of:
> 
> 1) sending from the client
> 2) receiving on the server
> 3) replying from the server
> 4) receiving the reply on the client
> 
> Our current code supports 1) and 2), but I've been having a bit of trouble
> with 3) and 4).
> 
> I suspect that I can get 3) to work on an endpoint server once I figure out
> what function to call to set the piggyback response message. However,
> problems arise if the server is acting as a proxy for the tunnel profile. A
> response cannot be sent until the entire tunnel has been setup, or setup has
> failed (ok or error message). I've tried to complete the setup of the next
> connection from within tunnel's server_init function, but it seems to get
> hung at the point where I try to open a new tcp beep connection to the next
> hop (rr_tcp_connection_new). Currently I'm getting around this problem by
> spawning off a thread to finish the setup and then send a non-piggybacked
> reply so that the server_init function is allowed to return. Since that
> method works, I'm guessing my problem is due to some sort of deadlock
> condition within the roadrunner libraries. Is this the case? Is there a
> work-around? Am I missing something?

You are correct, RoadRunner uses a fixed size thread pool. The current
default size of this pool is 1 (to make it easy to find this type of
problems).

Because of the fact that the maximum number of threads might be lower
then the maximum number of allowed connections you aren't allowed to do
certain things from within the profile. To avoid deadlocks you are not
allowed to call functions that require free work threads (like
rr_tcp_connection_new) from the functions
(client/server)_(init/confirmation), close_(indication/confirmation) and
frame_available.

One workaround that might work is to call:

	rr_set_max_work_threads (x);
	rr_listener_set_max_connections (listener, y);

where x >= y to make sure there always is free threads available.

/ Jonas
-- 
Jonas Borgström                  [email protected]
CodeFactory AB                   http://www.codefactory.se/
Office: +46 (0)90 71 86 14