Design questions

[stickben]

I have a few questions about the design of the sdk. how it interacts with the application code will drive the implementation of the application code.

- is the espcomm rx callback called from interrupt?
- can you save off the connection pointer in the rx callback and use it later?
- are the user tasks pre-emptive?
- can you start more than one TX at a time (for other connections) or should you always wait for the sent callback?

Is there any design documentation? It would be really nice to have some flow charts and data flow diagrams to show how data moves through the system.

Thanks!
Ben

[ESP_Faye]

Hi,

Here is an example of TCP connection http://bbs.espressif.com/viewtopic.php?f=21&t=232

- is the espcomm rx callback called from interrupt?
-> RX will trigger an 802.11 interrupt, 802.11 will post a message to lwip, espconn rx callback is in lwip.

- can you save off the connection pointer in the rx callback and use it later?
-> Please don't do that, because the pointer may be released in lwip (espconn disconnect callback & espconn reconnect callback)

- are the user tasks pre-emptive?
-> Without RTOS user tasks are not pre-emptive, with RTOS user tasks are pre-emptive.

- can you start more than one TX at a time (for other connections) or should you always wait for the sent callback?
-> To the same espconn connection, you need to wait for the sent callback or write finish callback.

Thanks for your interest in Espressif Systems and ESP8266 !

[stickben]

Thanks for the response, this really helps! How to you send data if you dont have the espconn *pointer?

For example:

I am writing a server, the server wants to occasionally send data to the client without the client sending to the server.

1-Server is listening
2-TCP client connects
3-I get the connect callback
4-Server waits 5 minutes.
5-Server needs to send data to the connected client

How do I send data to the connected client? The connect callback is over and the client has not sent data so I dont have a current espconn. Is there a way to look up the connection to get the espconn*?

Right now I am saving the espconn * from the connect callback and it seems to work, but I dont see any way to get the espconn * without the connect callback or data sent callback.

[kolban]

I think you have the right thinking. When you get the connect callback, the espconn structure supplied is your "handle" to future connections with the client. If you want to return from the connect callback and not send data to the partner then and there, then it is your responsibility to save the espconn reference so that when you eventually need it ... it will be there for you. I wouldn't look for any alternate ... my belief is that this recipe is exactly how it is intended to be used.

How you manage one or more espconn references is up to you.

Neil

[stickben]

Hmmm, still a little bit concerned. Espressif, can you provide a function to look up a connection based on remote port and ip? Or confirm that I can reuse the pointer in the connect callback?

[tve]

When you get a connection you're gonna need to save some information about it, for example, what the client requested, so you can put the espconn pointer into that structure as well. Basically you're going to need a struct of your own per connection and point to the espconn from that. In the espconn you can use the 'reverse' field to point back to your struct. The only tricky thing is that when you receive a disconnect or recon callback the espconn argument will have the reverse field properly set to point to your struct, but your struct's forward pointer to the espconn will be incorrect at that point (which doesn't matter much 'cause you can't do anything to the connection anymore anyway). I hope this helps.

[stickben]

Thanks, I will do that. My server already has a struct for each connection.

Ben

[ming]

The only tricky thing is that when you receive a disconnect or recon callback the espconn argument will have the reverse field properly set to point to your struct, but your struct's forward pointer to the espconn will be incorrect at that point (which doesn't matter much 'cause you can't do anything to the connection anymore anyway).

This is really correct and unfortunately I have learned it in a hard way.

The struct espconn pointer comes along with the disconnect or reconnect callback is indeed the espconn of the TCP server that you has created to "listen" for incoming TCP connection (called tcpServerEspconn hereafter), rather than the espconn of the "accepted" TCP connection (called acceptEspconn hereafter). But when the time to dismantle the accepted TCP connection comes, several parameters, including the reverse pointer, are copied from the acceptEspconn to tcpServerEspconn before destroying the acceptEspconn internally and calling the disconnect/reconnect callbacks.

So it is safe to keep acceptEspconn and use it to send/receive/etc until disconnect/reconnect callback is made. In those callbacks, the acceptEspconn pointer is no longer valid, and the most convenient way to find your data structure (where a reference of acceptEspconn is kept) is to use the reverse pointer, which you must set (very likely in the connect callback) when you first made a reference of acceptEspconn.