Asynchronous, acknowledged, point-to-point connection using gSoap

Question

Here's my situation:

1. I have a wsdl, "translated" to a header file like this: wsdl2h -o file.h file.wsdl
2. Then, I executed soapcpp2 -Icorrect_path -j file.h
3. On "server side" I implemented the service, using soapXXXService.[h|cpp]
4. On "server side" again, I used soap_init2 (with SOAP_IO_KEEPALIVE), I have soap_bind, soap_accept, soap_copy, etc. and it seems to work perfectly fine (see below)
5. On "client side", I use the generated proxy object (again using SOAP_IO_KEEPALIVE), construct the message and send it to the server
6. The "server" receives this message and sends back ACK (custom XML)
7. The "client" receives the ACK and everything is perfectly fine.

So, what I want to do now is make the "server" return the "real" response to the "client" and the "client" has to return back an ACK to the "server".

How is this possible? (it should be)

---

"What have you tried?"

Two things come to my mind.

The first is to somehow reuse the socket's file descriptor, returned from soap_accept, to send the "real response" back to the server. But Is this even possible?
Unix sockets are full duplex, so this is technically possible, but does gSoap restricts this? Because I didn't see anything about this in the documentation.

The second option, that comes to my mind is to create the same "service" in the "client", to make it possible to receive messages (the "real response") and to return ACK the same way it's done in the "server". But this would mean, that the "server" must also has an instance of proxy object to be able to send this so called "real response".
And this sounds really ugly and horrible to me. Not that I'll be surprised if this is the only option, but..

Edit: for the second option - this would mean, that the client should have a listener port, should handle incoming connections, etc. Does not sound like a client to me..

---

I understand, that I may be missing some fundamental part(s) of how gSoap works, but I read the whole user documentation and the "getting started" guide and I didn't find anything about this.

_{Please, let me know if something is not clear}

---

EDIT: Here's the scenario, I want to achieve:

1. client sends request to the server
2. server returns ACK as response (like the standard ACK) - signals successfully received request
3. later, the server sends response to the client (that's the real response)
4. the client returns ACK again - signals successfully received response

And this scenario could be in the opposite direction, too: server could also send request to the client. That would mean - the same scenario as above, but replacing "client" <-> "server".

NOTE: both request/response and ACK ARE SOAP messages.

Answer 1

I implemented it using option 2 in my question. That is: implement service (a listener) and use the proxy (for sending requests) in both - the client and the server. This way, I have the following:

1. The server is up
2. The client is started (starts a listener, a.k.a. "service")
3. The client sends SOAP request (using proxy object), telling the server: "I'm up and my location is xxx" (xxx is the URI, which will be used to connect the server to the client's listener)
4. The server responses with SOAP message (ACK) (saying: "OK, I see you're up now")
5. Later the server sends SOAP request (via proxy object) to the client, using the location, received in the first message; this request is the real response of the request, sent in 3. This says - "OK, I'm ready to communicate with you"
6. The client returns response to this request (ACK) (saying: "OK, cool")

And this way, both - the client and the server know each other's location, both have a listener (implementation of the service), both maintain proxy objects.

---

Seems like this will work for me. I'd be happy if somebody give me another option or say something about option 1 in my question.

---

EDIT: After deep research for several days and after deep analysis of the protocol, I intent to implement, it appeared, that that's the only way to do this:

Implementations MUST be able to function as both a SOAP client and a SOAP server