Hi,
To establish more connections using BSD sockets, I need to determine the best approach.
1)Should I implement multiple threads for this purpose? For example, I could use a threading model similar to the following:
https://www.keil.com/pack/doc/mw6/Network/html/group__bsd__routines.html#ga7005ffbeeff92be5394ff3244da79028
2) Alternatively, should I create a server thread and utilize the listen function with a backlog argument greater than 1? If that’s the case, I would need to manage incoming connections using the accept function to ensure they are handled.
listen
accept
3) As I see the Network debug window details, there is a bsd_cb_tcp callback function, but there is no information on how to implement or use it, Is there any resource?
4)How can I get the BSD socket states, such as Established, Connected, or others?"
5)Is there a function to determine the amount of available memory
1+2) Sorry, don't know what fits best in your application purpose. So I also can't give a recommendation.
3) As the BSD socket implementation uses the network libraries own native TCP and UDP sockets, they internally also use the callbacks to maintain BSD socket operation. You do not need to deal with it.
4) Not sure how perfect this works, be maybe you can poll a socket with non-blocking recv() calls and check the returned state. Or, maybe getpeername() might help. If it returns a valid peer, the socket should still be up.
5) Not sure what memory you mean.
Thank you, Andreas Barth, for your comment.
1,2) I need to establish five BSD connections between different devices and an STM32 MCU. Therefore, I need to listen on a specific port for each connection. When I was using TCP sockets, I utilized different socket objects, but with BSD connections, I need guidance on how to proceed.
3) Does this mean that I should create a new thread for each connection to manage all incoming connections as mentioned in this link?
Page:
https://community.arm.com/support-forums/f/keil-forum/56303/an-interruption-occurs-in-all-tcp-socket-connections-when-a-socket-connection-is-disrupted-either-by-disconnecting-the-ethernet-cable-or-by-powering-off-the-device
1+2+3) This is really something you need decide for yourself and what fits best your application needs. The BSD socket implementation is thread-safe for the most relevant part. As things can be used in non-blocking mode, it could work in a single thread and polling all sockets, or multi-threaded, using blocking calls on each socket.
5) And as the BSD sockets use the native TCP and UDP sockets underneath, the same memory management is used in this regard.
Dear Andreas Barth,
Thank you so much for your response! I truly appreciate your help. I have a couple of questions that I hope you can assist me with:
osThreadCreate (osThread(Server), (void *)SOCK_STREAM); osThreadCreate (osThread(Server), (void *)SOCK_STREAM); while(1) { osSignalWait (0, osWaitForever); }
listen(sock, 1)
ioctlsocket
Thank you again for your assistance.
I followed various steps, but the documentation on BSD is full of flaws, which has left me feeling confused. Is there an example of multiple BSD connections in MDK?
My code
sd = socket (addr.sin_family, type, 0); sck_mode = 1; ioctlsocket (sd , FIONBIO, &sck_mode); bind (sd, (SOCKADDR *)&addr, sizeof(addr)); listen (sd, 4);
The code above does not open more than one connection.
-------------
Some of the flaws:
https://www.keil.com/pack/doc/mw6/Network/html/group__bsd__routines.html#gac6b00a29e8f1664d7ba4a70bfb92d9db
In the sample code, the addr is a member of SOCKADDR_IN, which can't be sent to SOCKADDR (the fourth item in the recvfrom command).
addr
SOCKADDR_IN
SOCKADDR
recvfrom
https://www.keil.com/pack/doc/mw6/Network/html/group__bsd__routines.html#ga0b42eb9e32b55aff7130ef48afd8b885
In the sample code, SCK_SUCCESS is not defined. The correct term is BSD_SUCCESS.
SCK_SUCCESS
BSD_SUCCESS
In addition, I would like to understand how to determine when a request is sent to a non-blocking listener so that I can accept it using the accept command.
I would like to provide some clarification regarding my questions:
The MDK version 6 middleware you mentioned is outdated and is no longer being developed. It was abandoned almost 10 years ago. You can find the current MDK middleware documentation here.