Thank Simon, i´ll see the documentation,

Oscar

On Wed, Jul 22, 2009 at 6:13 AM, [email protected] <[email protected]> wrote:

> No, we don't provide recvmsg as it would be very big and we want the stack
> to be small. However, select *is* one of the standard BSD socket functions
> and very broadly used. I suggest you look at another documentation of the
> socket API as yours seems to be incomplete.
>
> Simon
>
>
> Oscar F wrote:
>
>> Thank you simon, but in my documentation of the API i haven't seen this
>> function "select()" in BSD socket. i'm not sure what if the purpose to call
>> this, because in general i understand the rest of function of the example. i
>> have seen in wikipedia the TFTP protocol and it's easy, but in the future
>> i've to implement my own protocol with TCP to send this, in fact i'll use
>> the BSD socket API to connect wih remote terminal and i interchange data of
>> my own protocol.
>>
>> I only know this function:
>>
>> _*2.2.1 *__*BDS librería de socket*_
>>
>> This section provides a simple implementation of the BSD socket API using
>> the lwIP API. Also, this implementation does not support the select() and
>> poll() functions of the BSD socket API since the lwIP API does not have any
>> functions that can be used to implement those. In order to implement those
>> functions, the BSD socket implementation would have to communicate directly
>> with the lwIP stack and not use the API.
>>
>> In the BSD socket API sockets are represented as ordinary file
>> descriptors. File descriptors are integers that uniquely identifies the file
>> or network connection. In this implementation of the BSD socket API, sockets
>> are internally represented by a netconn structure. Since BSD sockets are
>> identifed by an integer, the netconn variables are kept in an array,
>> sockets[], where the BSD socket identi¯er is the index into the array.
>>
>> The BSD socket API calls for setting up a connection are very similar to
>> the connection setup functions of the minimal API. The implementation of
>> these calls mainly include translation from the integer representation of a
>> socket to the connection abstraction used in the minimal API.
>>
>> *Funciones*
>>
>> a) int socket(int domain, int type, int protocol)
>>
>> The socket() call allocates a BSD socket. The parameters to socket() are
>> used to specify what type of socket that is requested. Since this socket API
>> implementation is concerned only with network sockets, these are the only
>> socket type that is supported. Also, only UDP (SOCK DGRAM) or TCP (SOCK
>> STREAM) sockets can be used.
>>
>> b) int bind(int s, struct sockaddr *name, int namelen)
>>
>> The bind() call binds the BSD socket to a local address. In the call to
>> bind() the local IP address and port number are specified. The bind()
>> function is very similar to the netconn bind() function in the lwIP API.
>>
>> c) int connect(int s, struct sockaddr *name, int namelen)
>>
>> The implementation of connect() is as straightforward as that of bind().
>>
>> d) int listen(int s, int backlog)
>>
>> The listen() call is the equivalent of the lwIP API function netconn
>> listen() and can only be used for TCP connections. The only di®erence is
>> that the BSD socket API allows the application to specify the size of the
>> queue of pending connections (the backlog). This is not possible with lwIP
>> and the backlog parameter is ignored.
>>
>> e) int accept(int s, struct sockaddr *addr, int *addrlen)
>>
>> The accept() call is used to wait for incoming connections on a TCP socket
>> that previously has been set into LISTEN state by a call to listen(). The
>> call to accept() blocks until a connection has been established with a
>> remote host. The arguments to listen are result parameters that are set by
>> the call to accept(). These are filled with the address of the remote host.
>>
>> When the new connection has been established, the lwIP function netconn
>> accept() will
>>
>> return the connection handle for the new connection. After the IP address
>> and port number of the remote host has been filled in, a new socket
>> identifier is allocated and returned.
>>
>> f) int send(int s, void *data, int size, unsigned int flags)
>>
>> In the BSD socket API, the send() call is used in both UDP and TCP
>> connection for sending data. Before a call to send() the receiver of the
>> data must have been set up using connect(). For UDP sessions, the send()
>> call resembles the netconn send() function from the lwIP API, but since the
>> lwIP API require the application to explicitly allocate buffrs, a buffer
>> must be allocated and deallocated within the send() call. Therefore, a
>> buffer is allocated and the data is copied into the allocated buffer.
>>
>> The netconn send() function of the lwIP API cannot be used with TCP
>> connections, so this implementation of the send() uses netconn write() for
>> TCP connections. In the BSD socket API, the application is allowed to modify
>> the sent data directly after the call to send() and therefore the NETCONN
>> COPY °ag is passed to netconn write() so that the data is copied into
>> internal buffers in the stack.
>>
>> g) int sendto(int s, void *data, int size, unsigned int flags,struct
>> sockaddr *to, int tolen)
>>
>> The sendto() and sendmsg() calls are similar to the send() call, but they
>> allow the application program to specify the receiver of the data in the
>> parameters to the call. Also, sendto() and sendmsg() only can be used for
>> UDP connections. The implementation uses netconn connect() to set the
>> receiver of the datagram and must therefore reset the remote IP address and
>> port number if the socket was previously connected. An implementation of
>> sendmsg() is not included.
>>
>> h) int write(int s, void *data, int size)
>>
>> In the BSD socket API, the write() call sends data on a connection and can
>> be used for both
>>
>> UDP and TCP connections. For TCP connections, this maps directly to the
>> lwIP API function
>>
>> netconn write(). For UDP, the BSD socket function write() function is
>> equvalent to the send() function.
>>
>> i) int recv(int s, void *mem, int len, unsigned int flags)
>>
>> In the BSD socket API, the recv() and read() calls are used on a connected
>> socket to receive data. They can be used for both TCP and UDP connections. A
>> number of args can be passed by the call to recv(). None of these are
>> implemented here, and the flags parameter is ignored. If the received
>> message is larger than the supplied memory area, the excess data is silently
>> discarded.
>>
>> j) int recvfrom(int s, void *mem, int len, unsigned int flags, struct
>> sockaddr *from, int *fromlen)
>>
>> The recvfrom() and recvmsg() calls are similar to the recv() call but
>> differ in that the IP
>>
>> address and port number of the sender of the data can be obtained through
>> the call.
>>
>> An implementation of recvmsg() is not included.
>>
>>
>> thank you again
>>
>> Regards
>>
>> Oscar
>>
>>
>>
>>
>>
>> On Tue, Jul 21, 2009 at 9:05 PM, [email protected] <mailto:
>> [email protected]> <[email protected] <mailto:[email protected]>> wrote:
>>
>>    Oscar F wrote:
>>
>>        Hello everybody, i'm using lwip 1.3.0 port to AVR for using in
>>        the board EVK1100.
>>
>>        Iḿ seeing a example code of tftp, and i don't understand this
>>        part, exactly the part to call the function lwip_select.
>>        Can anybody help me?
>>
>>        and where is the documentation for all API and struct, i only
>>        have these kind of documents
>>
>>
>>    >From having a quick look at the code below, it is not using
>>    lwIP-specific API functions at all, but simply the socket API,
>>    which is a compatibility API to the standard BSD socket interface
>>    (select() is also a BSD-socket-API function). The only difference
>>    is you are using the internal names (with lwip_ at the front).
>>
>>    Since you don't seem to know your way, you should start with a
>>    socket reference (either opengroup - e.g. use google to search
>>    "opengroup select"; or microsoft MSDN - be aware that microsoft
>>    doesn't follow the standard everywhere, but they are mostly
>>    compatible to us and sometimes have great example code).
>>
>>    Simon
>>
>>
>>    _______________________________________________
>>    lwip-users mailing list
>>    [email protected] <mailto:[email protected]>
>>    http://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> lwip-users mailing list
>> [email protected]
>> http://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>
>
>
> _______________________________________________
> lwip-users mailing list
> [email protected]
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users

Reply via email to