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.

Fatso

I think I understand now. I'm pulling down my initial answer. – Stowaway

Question about points 1, 2 & 3. Do you need your client to send its request, get a quick "ack", then to be able to go off and do other things, and then later check back to see if it received the final response? If this is the case, you could instead make your client multithreaded and eliminate the first "ack". Have it send the request, and wait for the final response on a worker thread, while the main thread of the client goes on to do useful work. – Stowaway

Question about point 4. Why is the ack from the client back to the server required? If it is needed, that can be handled by the section 7.4 of the gSOAP docs. – Stowaway

Question about the reversal of roles for the client and server. Will the possibility of the client receiving a request from the server happen without warning? Meaning, no action of the client's part will cause the server to send a SOAP request to the client? If this is true, then the client will also need to implement a SOAP server, with a listener . – Stowaway

@DaveNewman - sorry for the late responses. For your first comment - yes, that's what I need, I have additional thread, BUT I'm implementing a standard protocol (which relies on SOAP) and I cannot eliminate anything. My client should be able to communicate with other servers, too. – Fatso

About the second comment - yes, it's necessary, as it's defined by the standard (it tells the server, that that client has received the response and that the received response is valid message). – Fatso

About the last one - yes, it can receive messages (commands for configuration, for example or for reporting different statuses of different devices) at any moment. Only one thing is required first - on start, the client will send its location to the server and it will tell the server, that it's up and ready for processing commands (which may appear at any moment after the initial message). – Fatso

All of this makes me think, that I should implement option 2 (from my question). I just wonder if there's another way to do this or that's the only way, this can be achieved. – Fatso

let us continue this discussion in chat – Stowaway

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

Fatso