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 ?
state machine?
Err. I don't understand. I already have a state machine.
The point is that I CAN NOT CONTROL when TCP data is received. It comes into a callback function, which means I MUST deal with it there and then, whatever my state machine is doing. I want to defer dealing with it. If I had infinite resources of memory, I could buffer everything up. I don't have infinite resources.
How do you suggest I implement a state-machine to achieve this ? I'm using a state machine for sending TCP data and using the callback for handling reception.
What I would like to do is to be able to "peek" to see if there is another TCP packet incoming and only deal with it when my state machine is ready to do so. I can't do this, because the callback mechanism effectively works asynchronously to the state machine.
Richard, I have to admit that I never worked with TCP/IP in an embedded environment (that is going to change...). I can only offer you some help based on my experiences in a PC environment. the API 'recv' in windows environment
int recv( SOCKET s, char FAR *buf, int len, int flags );
offers the 'flags' parameter which can also be: MSG_PEEK, which peeks at the incoming data. The data is copied into the buffer but is not removed from the input queue. The function then returns the number of bytes currently pending to receive.
you can also create a blocking socket by using the 'ioctlsocket' API, FIONBIO command. this API also allows peeking at what the socket has in store, but I guess it is very platform/application specific. you may be able to use 'setsockopt' to setup different parameters. generally, if you can use built-in buffers of TCP/IP, your problem is solved.
Oops, I did work with TCP/IP in an embedded environment but it was with the support of TCP/IP library for vx-works. Am I correct in assuming that you are not working with an RTOS...?