I have written a small embedded TCP/IP server application but it needs to work lock-step: one query then one response.
My problem is that the client (not under my control) making the requests is running ahead and I don't have the resources to buffer-up an arbitrarily large number of queries.
When a query comes in to the server, it arrives in the tcp_callback function. Data is arriving before I've fully sent the response to the previous one.
How do I impose some flow control on incoming data so that I can do things lock-step ?
You will have additional socket attribute TCP_TYPE_FLOW_CTRL. If you open a TCP socket with this attribute set, TCPnet will control the Window Size.
When a TCP packet is received TCPnet sends an ACK with a window size reduced by the size of received data. This will soon stop the sending host because the window size will be too small (or 0) for the sending host to send further data.
If you will not call an tcp_reset_window() function, remote host will send only the TCP_DEF_WINSIZE bytes and will then stop, waiting for a TCP Window Update packet to be able to continue.
All the packets will be anyway ACKed correctly. After you have processed all the data, you will call tcp_reset_window() function. This will send an TCP Window Update pakcet to the remote host. After receiving this packet, remote host will continue sending data.
Franc
I did a search and stumbled across this thread because I was trying to work out how I can write a wrapper to give a BSD-like interface for the Keil TCP/IP stack.
We may end up using a third-party HTTP server instead of the Keil one because we want enhancements such as the ability to use the input="file" control for XML configuration file upload, and also SSL security. But such a third-party embedded HTTP server will want to see a BSD interface.
I'm hoping that, by using the new flow control feature, I can create a wrapper function that simulates a blocking or non-blocking recv() function.
Does anyone have any comments about the feasibility of this? I confess that I am quite new to TCP/IP and BSD interfaces.
Trev
Since you'll be using external libraries for SSL and web server, which will take some effort to integrate into your application, you might as well choose a more advanced TCP/IP stack. Have a look at lwip: savannah.nongnu.org/.../ It's a rather mature project and it provides a Berkeley socket API if you need it. I've used it on 2 different MCU architectures already. It lacks a good manual, but the project is alive and well. Depending on your application, it might also make sense to use Linux as your OS, which would allow you to tap into the vast pool of open-source software for Unix-like OS'es.
Thanks Mike. The web server is a 'bolt on' for an existing project commercial project and unfortunately use of an OS like Linux just isn't going to be able to happen, but I certainly take your point and appreciate the advice.
The secure web server applications I've been looking at are those available from the likes of Unicoi and Allegro; I was thinking that the most hassle-free solution might be to get the HTTPS server and TCP/IPv4 stack from the same vendor. From the company point of view it's probably best to buy a commercial license that gets us the support and so forth.
I'll have a look at lwIP - thanks for the pointer. I'll have to find out what their licensing terms are for a commercial project.
Trevor, I agree that getting a commercial license for a TCP/IP stack and HTTPS server from the same vendor makes a lot of sense. The cost of licensing is substancial for me, so I tend to explore open-source solutions first. That's why I suggested lwip. By the way, its license is BSD-like. But I believe you are aware of these subtleties, and my suggestions will not throw you off course.
Regards, - mike