• State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 22 subscribers
  • Views 896 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

RL-ARM: Allocation then release of listening socket

David Rose

I am trying to produce a module for providing a listening socket.

One requirement of this module is to release the socket when it is no longer required.

So the code does something like this:


int Skt;

Skt = tcp_get_socket( TCP_TYPE_SERVER|TCP_TYPE_FLOW_CTRL, 0, 30, Callback);

...

// Remote client access the socket - And then closes the connection

...

// A call to tcp_get_state(Skt) returns TCP_STATE_LISTEN

if (!tcp_release_socket(Skt))
  // Failure - And I don't understand why

My problem is that the attempted release of the socket always fails.

When I carry out a similar sequence for a TCP_TYPE_CLIENT (as opposed to the TCP_TYPE_SERVER) the release of the socket is successful.

Can anyone tell me, am I missing something? it surely is possible with this library?

  • 0

    But server-side sockets are normally available the full life of the application, wo maybe Keil hasn't added support to release it.

    Without a server-side socket, how are you going to tell your application when it is time to create the socket, so that someone from the outside can connect?

  • 0 in reply to ImPer Westermark

    Per,

    Thanks for your response.

    "But server-side sockets are normally available the full life of the application, wo maybe Keil hasn't added support to release it."

    Normally, but not always.

    "Without a server-side socket, how are you going to tell your application when it is time to create the socket, so that someone from the outside can connect?"

    The someone in this instance is normally a something (e.g., a service running on a PC). If the TCP session is closed or is refused, then it periodically attempts to re-connect. Don't think there's anything unusual about that.

    For this series of projects, the device will normally be listening for remote connections; but, at certain points in the operational life, will require the socket to become unavailable. Closure of the socket seems a sensible way to achieve that.

    I don't consider this to be particularly unusual - I have implemented this precise action a number of times on various platforms and have seen the same action on other equipment.

    Maybe Keil, like yourself, did not see the need.

    I think an email to Keil support might be appropriate here.