HTTP POST with WIP library on SL8082T

Hi Guys,

I’m just wondering if anyone can shed light on what might be going wrong here.

I’m posting a string to an endpoint, and the string is being logged by the server with no problems, BUT, I never receive the OK response - this means I never get a WIP_READ event and no finalizer is ever triggered, which is causing big problems for my code in terms of carrying on. I can forcibly close the channel with wip_close(my_channel) but I then need to make sure the data has actually been transmitted first and it gets very messy.

I’ve included the two lines of code that 1st set up the http channel and 2nd set up the post channel - I have replaced the endpoint as I can’t share that.

I have tried endpoints such as where I get an OK reply but no post data seen (chunked data not supported?).

http = wip_HTTPClientCreateOpts(NULL, NULL, WIP_COPT_HTTP_HEADER, "User-Agent", "WIP-HTTPClient/1.0", WIP_COPT_END);

post_channel = wip_getFileOpts( http, "", http_event, NULL, WIP_COPT_HTTP_METHOD, WIP_HTTP_METHOD_POST, WIP_COPT_HTTP_HEADER, "Accept", "text/html", WIP_COPT_FINALIZER, POST_finalizer, WIP_COPT_END);

Also, may or may not be related:

After the module has generated about 40 posts I get a WIP_CERR_MEMORY error, I have no idea why as all other adl_memGet and adl_memRelease functions continue to work with no problems. The stack size is also 32768 and the size has no bearing on how long it takes the errors to start to appear… Any thoughts?


I’ve never used the SL8082T, but using when using the WIP library on a Q2686, you have to wip_shutdown() the write channel after completing your POST wip_write(). If you don’t do the wip_shutdown(), you will never get the read events with the OK (and potentially other data) back from your server.

Note that this is NOT well documented in the WIP guide.

Have a look in your WIP doco and see if there is a wip_shutdown() that you can call at the end of your WIP_WRITE event handler.

With regards to the error, I suspect that you are exhausting all the resources inside the WIP library - probably because you’re not closing your channels correctly when you’ve finished.

Hope this helps.

ciao, Dave

Thanks for the insight, Dave.

I really have been scratching my head over this one, specifically because of the dire SiWi documentation.

I will try this as soon as I can!

Quick update,

This has certainly done the trick for getting the reply from the server, as you said.

I am still occasionally getting WIP_CERR_MEMORY reported, however (approx. every 20 posts). This is certainly less frequent and on a different schedule to before, but I still need to weed this out…


Good news!

Glad to hear that you’re getting two way traffic now.

I suspect you’re getting the WIP_CERR_MEMORY event as you’re not cleaning up something properly at the end of your transmission - probably not closing the channel(s) appropriately, or there’s issues with your context variables (if you’re using them)>

ciao, Dave


You found a solution? What’s your http posting time? 1 post per min? 1 post per hour?

I have same problem with memory resources, I’m not using HTTP POST, I am using only TCP sockets, but I can see that is almost the same problem because I also used HTTP POST several times.

  1. I connect to a server and send data
  2. If server close connection due to connection problem, or TCP connection timeout I close the socket
  3. Open a new socket. Sometimes I don’t receive WIP_CEV_OPEN, I receive WIP_CERR_TIMEOUT, so I close again.

If server keeps droping connection, about 8-10 times, I receive next trace:
ADL;1;ERRLOG …/src/ch_tcp_client.c:103: No more free socket

I read WIPlib doco that each TCP socket reserve heap memory, but after closing socket it doesn’t release the memory inmediatly, so if you can open 8 or 10 sockets, and keep closing-opening sockets you are reducing future available sockets until memory releases. That’s why is WIP_COPT_FINALIZER on wip_TCPClientCreatOpts to call a function when these memory is released. So I don’t now how much time memory will release, only will receive a notification when it’s released (never waited too much to receive this function called).

I see your are using the same WIP_COPT_FINALIZER, you wait long enough to see if your function is called?

I’m not using context variables, not a problem related to this for my problem. HTTP api open and close it’s used sockets, if this api can’t handle 20 sequently posts it’s really a problem, or maybe we should “give a hand” to http api to close sockets properly.

I’m going to test wip_abort() instead wip_shutdown() before wip_close() to abort TCP pending data, specially if WIP_CERR_TIMEOUT is received to see if memory is released faster. If not… would be great if someone know what’s average time that wip realeases memory allocated for TCP/UDP sockets? Or a faster time to release memory.

Best regards,

Ok so here’s how I’ve sorted mine.

I’m still unsure if my code that finishes off POSTs is tidying up properly - but I have code that checks what’s going on in the beginning of the next POST as a guard.

I had a typo in this and this is why I was getting the problem…

		TRACE (( 4, "Tidying up old http channel" ));
		http = NULL;

		TRACE (( 4, "Tidying up old POST channel" ));
		post_channel = NULL;

I close off both the http channel and the post channel before creating new ones. I’m not exactly clear on which I actually need to close and recreate (some need a close/abort/whatever to allow data to be sent) - since there is no state diagram in the user guide for HTTP like there are for other approaches and so I’m not sure if this can be streamlined.

No more WIP_CERR_MEMORY errors, anyway!