This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to prevent TCP/IP reception until I'm ready

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 ?

Parents
  • 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

Reply
  • 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

Children
  • 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