prob with active objects .. for TCP sockets ..

I'm still not very good at this, since I'm also trying to use it myself in my thesis...

But you did not seem to have issued a request for your passive active object. According to my experiences (basic trial and error, and struggling to understand the documentation), you need to issue a request in a function (which is not the RunL() function), in order for RunL() to be executed.

Hence what I usually do is to have a Start() function...

void Start()
{
 some_request(..., iStatus);
 SetActive();
}

and then, RunL() will be executed without any trouble...

Hi,

There are few things you misunderstood.

First, RSocket::Listen is not an asynchronous call. Thus, it's meaningless to call SetActive right after invoking Listen. This method is a synchronous one and as such you can simply continue your code with preparing for a call to RSocket::Accept.

Second, you might ask : if Listen is not an asynchronous call, then why its RunL is called? Well, I have two remarks on this :
- you do not have to call an asynchronous service in order to get your RunL called by the AS (active scheduler). You simply have to assign KRequestPending to your iStatus and call SetActive and after that your RunL will be called some time.
- I realized that you did not change your request status, thus your RunL should not have been called at all. It is surprising to me, I can't help on this.

Third, do not forget that calling User::WaitForRequest should not be the preferred solution as it blocks the whole thread.

Fourth, you did not mention whether your active socket's (i.e. that wants to connect to another socket) Open method leaves or not. It might be questionable, because if your iSession member is the same RSocketServ object (is it an RSocketServ at all?) that is used by the other sockets, then calling RSocketServ::Connect the second time will result in a failure. Thus, your active socket's Open will leave as you issued a User::LeaveIfError.

Finally, If I were you I'd implement this as follows :


Hope it helps,

tOtE

Hi,

I think it is still enough to use
that is, 1 is enough. It specifies the number of spare slots for incoming connections. The slot becomes spare again as soon as RSocket::Accept completes, I guess.

Blank sockets : well, I have not done things like that earlier, but my opinion is as follows. You use a blank socket, because you do not know the characteristics of a remote socket in advance. When the two sockets (i.e. local and remote) are coupled, your local (and hitherto blank) socket is configured by the remote socket. After the connection is set up, it is no more a blank socket. Thus, in order to make it possible to listen (and accept) to new incoming connection requests, you have to create another blank socket and pass it to iListeningSocket's Accept method.

Example : you are a server, peering for incoming connections and maintaining current connections simultaneously. Assume that there are three established connections. What is the situation with sockets?
1 listening socket, it is pending (RSocket::Accept has not yet completed),
1 blank socket, it is passed to the listening socket,
3 properly configured sockets that are the local end-points of the connections currently "running".

Finally, AS : well, I do not fully understand the mechanism of it either, but after reading the documentation (and as I've got a few years experience) I think it is done as follows.
The AS is interested in various events, thus it issues a User::WaitForAnyRequest. This request blocks the thread (I'm not sure about this, however), so nothing can be done meanwhile, only if an AO is completed. Don't forget that the program execution is nothing else, but running AOs' RunL method, one after the other. If something happens in your program, it will always be in an AO's RunL. Thus, the AS's User::WaitForAnyRequest completes only when an AO's state changes. If there are no AOs in the AS's queue, then it will never be possible to add a new (i.e. the very first) AO as the whole thread is blocked. If User::WaitForAnyRequest happened to complete, but there is no appropriate AO in the AS's queue, then a stray signal occurs, which results in a panic in the current thread.

That's all!

tOtE