Setting up remote channels

[Paolomio]

Working on constructing a client/server system, and trying to work through a chicken-egg conundrum. The documentation for GETR says "a program normally receives a channel-end over an already connected channel..." and also "to connect the first remote channel, a channel-end identifier can be constructed..."

So to connect a channel the program has to receive the remote channel end from an already connected channel. Or a program has to use a hard-coded channel-end for the remote side with the assumption that it isn't already allocated. This seems like an unclean solution...

Either that, or I'm missing something.

I'm going with this last one...

I'd like for a client to be able to connect to a server's channel, have the desired exchange, and free the channel again so another client can connect. This seems relatively easy except for the getting-the-server's-channel id part.

Can someone straighten me out on this?

Thanks,

Paul

[segher]

To "free a channel", you don't need to free the channel ends.

You can use any local channel end to talk to any remote channel end;
to do that, you use a SETD insn, and start talking. While you are
talking, no other channel end can talk to the remote channel end,
until you send an END (or PAUSE) token.

If the remote channel end wants to talk back to you, the remote side
needs to do a SETD as well; for this reason, you usually start the
"conversation" with your own local channel end id.

Now the chicken and egg issue: when two cpus haven't talked to
each other yet, there is no way for them to have communicated any
channel end ids, of course. So to get everything started, you will
have to use some hard-coded channel end id.

The simplest way is for all slaves, as part of their initialisation routine,
to do a "GETR xxx,2" (which will always get chanend #0, since it is the
first chanend it gets), and listen on it for a message from the master.
The master can then tell it about the chanend(s) it wants to communicate
on, and whatever else you need for initialisation.

[Paolomio]

Now the chicken and egg issue: when two cpus haven't talked to
each other yet, there is no way for them to have communicated any
channel end ids, of course. So to get everything started, you will
have to use some hard-coded channel end id.

The simplest way is for all slaves, as part of their initialisation routine,
to do a "GETR xxx,2" (which will always get chanend #0, since it is the
first chanend it gets), and listen on it for a message from the master.
The master can then tell it about the chanend(s) it wants to communicate
on, and whatever else you need for initialisation.

That's pretty much what I thought might be the solution, but my brain just didn't quite want to believe it. It's sort of an odd architecture in this particular spot.

Thanks for the quick answer!

Paul