Last modified on 10 October 2012, at 09:36


Navbar for the Aros wikibook
Aros User Docs
Aros User Docs
Aros User FAQs
Aros User Applications
Aros User DOS Shell
Aros Dev Docs
Aros Developer Docs
Porting Software from AmigaOS/SDL
For Zune Beginners
Zune .MUI Classes
For SDL Beginners
Aros Developer BuildSystem
Specific platforms
Arm Raspberry Pi Support
Motorola 68k Amiga Support
Android Support
Linux and FreeBSD Support
Windows Mingw and MacOSX Support
Aros x86 Installing
Aros x86 Audio/Video Support
Aros x86 Network Support
Aros x86 Complete System HCL
Aros Storage Support IDE SATA etc
Aros Poseidon USB Support
x86-64 Support
PPC Power Architecture
Aros Public License


create socket
set sock addr
set sock port
open socket
send socket ( request_string )
receive result
#include <proto/socket.h>
#include <bsdsocket/socketbasetags.h>

The bsdsocket.library get created in memory once you start the AROSTCP. Those included will supply the links for it.

#include <proto/exec.h>
struct Library * SocketBase = NULL;
int h_errno = 0;
extern int errno;

and then in the initialization code:

if(!(SocketBase = OpenLibrary("bsdsocket.library", 4 ))) {
SDLNet_SetError("No TCP/IP Stack running!\n");

if( SocketBaseTags(SBTM_SETVAL(SBTC_ERRNOPTR(sizeof(errno))), (IPTR)&errno,
SDLNet_SetError("Error initializing bsdsocket\n");

changed the include dir for the networking apps to $(AROS_DEVELOPMENT)/netincludes had to change #include <bsdsocket.h> to include <proto/bsdsocket.h> bsdsocket.library doesn't exist as a binary in libs:. It is created on-the-fly after you do "startnet"

redefine SocketBase to a non-global variable, such as a field in a thread-specific context. E.g.:

#define SocketBase my_thread_context->socket_base 

looked at the Task struct and it has tc_UserData, just what I needed I could use this to hold the SocketBase for each task. This approach will work, even if I want to use sockets in the main program. In case someone is interested, I created this little header:


 * Per-task socketbase using tc_UserData

#include <proto/exec.h>

#define SocketBase FindTask(NULL)->tc_UserData
#include <proto/bsdsocket.h>


Included this everywhere instead of proto/bsdsocket.h, and used SocketBase as normal.

WaitSelect() works just like select() and would be nice to paste bit of the code here where it fails... sys/select.h WaitSelect can only be used on sockets, not on DOS filehandles. On unix they are handled uniformly, but on Amiga you have to use different code path for file handles and sockets.

#ifndef select(nfds,rfds,wfds,efds,timeout)
#define select(nfds,rfds,wfds,efds,timeout) WaitSelect(nfds,rfds,wfds,efds,timeout,NULL)

and the test the select

struct timeval timeout;
int socket_d;
struct fd_set client_d;

//set to 3 mins
timeout.tv_sec = 3 * 60;
timeout.tv_usec = 0;


rc = select(socket_d + 1, &client_d, NULL, NULL, &timeout);

/* Check to see if the select call failed. */
if (rc < 0)
perror(" select() failed");

/* Check to see if the 3 minute time out expired. */
if (rc == 0)
printf(" select() timed out. End program.\n");


socket -- create an endpoint for communication


     #include <sys/types.h>
     #include <sys/socket.h>
     int socket(int domain, int type, int protocol)


    Socket() creates an endpoint for communication and returns a

    The domain parameter specifies a communications domain within which
    communication will take place; this selects the protocol family
    which should be used.  These families are defined in the include
    file <sys/socket.h>.  The currently understood formats are

         AF_UNIX         (UNIX internal protocols),
         AF_INET         (ARPA Internet protocols),
         AF_ISO          (ISO protocols),
         AF_NS           (Xerox Network Systems protocols), and
         AF_IMPLINK      (IMP ``host at IMP link layer).

    AROS AMITCP/IP currently supports only AF_INET protocol family.

    The socket has the indicated type, which specifies the semantics of
    communication.  Currently defined types are:


    A SOCK_STREAM type provides sequenced, reliable, two-way connection
    based byte streams.  An out-of-band data transmission mechanism
    may be supported.  A SOCK_DGRAM socket supports datagrams
    (connectionless, unreliable messages of a fixed (typically small)
    maximum length).  A SOCK_SEQPACKET socket may provide a sequenced,
    reliable, two-way connection-based data transmission path for
    datagrams of fixed maximum length; a consumer may be required to
    read an entire packet with each read system call.  This facility
    is protocol specific, and presently implemented only for PF_NS.
    SOCK_RAW sockets provide access to internal network protocols
    and interfaces.  The types SOCK_RAW, which is available only to
    the super-user, and SOCK_RDM, which is planned, but not yet
    implemented, are not described here.

    The protocol specifies a particular protocol to be used with the
    socket.  Normally only a single protocol exists to support a
    particular socket type within a given protocol family.  However,
    it is possible that many protocols may exist, in which case a
    particular protocol must be specified in this manner.  The
    protocol number to use is particular to the "communication domain"
    in which communication is to take place.

    Sockets of type SOCK_STREAM are full-duplex byte streams, similar
    to pipes.  A stream socket must be in a connected state before any
    data may be sent or received on it.  A connection to another
    socket is created with a connect() call.  Once connected, data may
    be transferred using recv() and send() or their variant calls.
    When a session has been completed a CloseSocket() may be
    performed.  Out-of-band data may also be transmitted as described
    in send() and received as described in recv().

    The communications protocols used to implement a SOCK_STREAM insure
    that data is not lost or duplicated.  If a piece of data for which
    the peer protocol has buffer space cannot be successfully
    transmitted within a reasonable length of time, then the
    connection is considered broken and calls will indicate an error
    with -1 returns and with ETIMEDOUT as the specific error code (see
    Errno()).  The protocols optionally keep sockets "warm" by forcing
    transmissions roughly every minute in the absence of other
    activity.  An error is then indicated if no response can be
    elicited on an otherwise idle connection for a extended period
    (e.g. 5 minutes).

    SOCK_SEQPACKET sockets employ the same system calls as SOCK_STREAM
    sockets.  The only difference is that recv() calls will return
    only the amount of data requested, and any remaining in the
    arriving packet will be discarded.

    SOCK_DGRAM and SOCK_RAW sockets allow sending of datagrams to
    correspondents named in send() calls.  Datagrams are generally
    received with recvfrom(), which returns the next datagram with its
    return address.

    An IoctlSocket() call can be used to specify a task to receive a
    SIGURG signal when the out-of-band data arrives.  It may also
    enable non-blocking I/O and asynchronous notification of I/O events
    via SIGIO.

    The operation of sockets is controlled by socket level options.
    These options are defined in the file <sys/socket.h>.
    setsockopt() and getsockopt() are used to set and get
    options, respectively.


    A -1 is returned if an error occurs, otherwise the return value is
    a descriptor referencing the socket.


    The socket() call fails if:
         The protocol type or the specified protocol is not supported
         within this domain.

         The per-process descriptor table is full.

         Permission to create a socket of the specified type and/or
         protocol is denied.

         Insufficient buffer space is available.  The socket cannot be
         created until sufficient resources are freed.


    socket() calls the fdCallback() with action codes FDCB_CHECK and
    FDCB_ALLOC to check and mark the new descriptor as allocated
    if the callback is defined.  See SocketBaseTagList() for more
    information on fdCallback().

Some sample code tutorial


SocketBaseTagList -- Set/Get SocketBase attributes.


    #include <amitcp/socketbasetags.h>

    ULONG SocketBaseTagList(struct TagItem * taglist);

    ULONG SocketBaseTags(ULONG tag, ...);


    Set or get a list of (mostly) SocketBase instance dependent
    attributes from the AMITCP/IP.


    These functions expect as their argument a standard tag list, one
    or several array of struct TagItem as defined in the header file
    <utility/tagitem.h>. The structure contains two fields: ti_Tag
    and ti_Data.  The ti_Tag field contains tag code, which determines
    what the SocketBaseTagList() should do with its argument, the
    ti_Data field.

    The include file <amitcp/socketbasetags.h> defines macros for base
    tag code values.  Base tag code macros begin with `SBTC_' (as
    Socket Base Tag Code).  The base tag value defines what data item
    the tag item refers.

    The tag code contains other information besides the referred data
    item.  It controls, whether the SocketBaseTagList() should set or
    get the appropriate parameter, and whether the argument of the tag
    in question is passed by value or by reference.

    The include file <amitcp/socketbasetags.h> defines the following
    macros, which are used to construct the ti_Tag values from the base
    tag codes:
         SBTM_GETREF(code) - get by reference
         SBTM_GETVAL(code) - get by value
         SBTM_SETREF(code) - set by reference
         SBTM_SETVAL(code) - set by value

    If the actual data is stored directly into the ti_Data field, you
    should use the 'by value' macros, SBTM_GETVAL() or SBTM_SETVAL().
    However, if the ti_Data field contains a pointer to actual data,
    you should use the 'by reference' macros, SBTM_GETREF() or
    SBTM_SETREF().  In either case the actual data should always
    be a LONG aligned to even address.

    According the used tag naming scheme a tag which has "PTR" suffix
    takes an pointer as its argument.  Don't mix the pointer arguments
    with 'by reference' argument passing.  It is possible to pass a
    pointer by reference (in which case the ti_Data is a pointer to
    the actual pointer).

    The list of all defined base tag codes is as follows:

         Tag data contains the INTR signal mask.  If the calling task
         receives a signal in the INTR mask, the AMITCP/IP interrupts
         current function calls and returns with the error code EINTR.
         The INTR mask defaults to the CTRL-C signal (SIGBREAKF_C,
         bit 12).

         Socket Descriptor Table size. This defaults to 64.

         The errno value. The values are defined in <sys-errno.h>.

         Set (only) the pointer to the errno variable defined by the
         program.  AMITCP/IP defines a value for this by default, but
         the application must set the pointer (and the size of the
         errno) with one of these tags, if it wishes to access the
         errno variable directly.

         The SBTC_ERRNOPTR(size) is a macro, which expands to one of
         the other (BYTE, WORD or LONG) tag codes, meaning that only
         1, 2 and 4 are legal size values.

         The NetLib:autoinit.c sets the errno pointer for the
         application, if the application is linked with it.

         Returns an error string pointer describing the errno value
         given on input. You can not set the error message, only get
         is allowed.

         On call the ti_Data must contain the error code number.  On
         return the ti_Data is assigned to the string pointer.
         (*ti_Data, if passed by reference).  See the file
         <sys-errno.h> for symbolic definitions for the errno codes.

         A callback function pointer for coordination of file
         descriptor usage between AMITCP/IP and link-library.  By
         default no callback is called and the value of this pointer
         is NULL.  The prototype for the callback function is:

         int error = fdCallback(int fd, int action);

              - 0 for success or one of the error codes in
              <sys-errno.h> in case of error. The AMITCP/IP API
              function that calls the callback usually returns the
              error back to the caller without any further

              - file descriptor number to take action on.

              - one of the action codes, which are defined in the
              header file <amitcp-socketbasetags.h>) as follows:

                   - mark the fd as unused on the link library
                   structure. If fd represents a file handled by the
                   link library, the error ENOTSOCK should be returned.

                   - mark the fd allocated as a socket.

                   -check if the fd is free. If an error is returned,
                   the fd is marked as used in the AMITCP/IP

         The AMITCP/IP calls the callback every time a socket
         descriptor is allocated or freed. AMITCP/IP uses the
         FDCB_CHECK before actual allocation to check that it
         agrees with the link library on the next free descriptor
         number.  Thus the link library doesn't need to tell the
         AMITCP/IP if it creates a new file handle in open(), for

         See file _chkufb.c on the net.lib sources for an example
         implementation of the callback function for the SAS/C.

         The name resolver error code value. Get this to find out why
         the gethostbyname() or gethostbyaddr() failed. The values are
         defined in <netdb.h>.

         Returns host error string for error number in tag data.  Host
         error is set on unsuccessful gethostbyname() and
         gethostbyaddr() calls. See the file <netdb.h> for the
         symbolic definitions for the herrno valus.

         Notes for the SBTC_ERRNOSTRPTR apply also to this tag code.

         Returns an error string for standard AmigaOS I/O error number
         as defined in the header file <exec-errors.h>.  Note that the
         error number taken by this tag code is positive, so the error
         codes must be negated (to be positive).  The positive error
         codes depend on the particular IO device, the standard
         Sana-II error codes can be retrieved by the tag code

         Notes for the SBTC_ERRNOSTRPTR apply also to this tag code.

         Facility code for the syslog messages as defined in
         <sys/syslog.h>.  Defaults to LOG_USER.

         Sets the filter mask of the syslog messages.  By default the
         mask is 0xff, meaning that all messages are passed to the log

         Syslog options defined in <sys/syslog.h>.

         A pointer to a string which is used by Syslog() to mark
         individual syslog messages. This defaults to NULL, but is set
         to the name of the calling program by the autoinit code in
         netlib:autoinit.c.  This is for compatibility with pre-3.0

         Returns an error string for a Sana-II specific I/O error code
         as defined in the header file <devices-sana2.h>.

         Notes for the SBTC_ERRNOSTRPTR apply also to this tag code.

         Returns an error string for a Sana-II Wire Error code as
         defined in the header file <devices-sana2.h>.

         Notes for the SBTC_ERRNOSTRPTR apply also to this tag code.

         Tag data contains the signal mask to be sent to the
         application whenever notification about socket events is in
         order.  The default value for this is zero, inhibiting any
         event notifications.  The application must set this mask if
         it desires to be notified about asynchronous socket events.
         When the application receives the signal specified in the
         mask, it can use the function GetSocketEvents() to find out
         what happened.

         The signals specified in the mask in the tag data are sent to
         the calling task when asynhronous I/O is to be notified. The
         default value is zero, i.e., no signals are sent. The signals
         in the mask are sent whenever something happens on the
         socket. This mechanism is compatible with the Unix SIGIO

         Since AmigaOS signals may get combined, one signal may include
         notification for originally distinct events on the socket.
         One example of this is the reception of data and connection

         Usage of the socket events (see GetSocketEvents()) is
         recommended over this because of the problem described above.

         The signals specified in the mask in the tag data are sent to
         the calling task when notification about urgent data arrives.
         The default value is zero, i.e. no signals are sent. This
         mechanism is compatible with the Unix SIGURG signal.

         Note that this signal does not indicate the arrival of the
         actual out-of-band data. If the receive buffer of the socket
         is full, the urgent data can't even be received. Because of
         this the application may need to read some normal data off
         the socket before it can read the urgent data.


    Returns 0 on success, and a (positive) index of the failing tag on
    error.  Note that the value 1 means first TagItem, 2 the second
    one, and so on.  The return value is NOT a C-language index, which
    are 0 based.


extern LONG WaitSelect(rest);
int select(int nfds,fdset *readfds,rest) just like the header
return WaitSelect(rest);
if your problem was O_NONBLOCK than why dont you actually use that setnonblocking()
function to enable non-blocking I/O instead of directly calling fcntl()????
also you may want to use O_NDELAY
O_NONBLOCK and O_NDELAY are same if you can use O_NDELAY
<source lang="c">
int setNonblocking(int fd)
int flags;
/* If they have O_NONBLOCK, use the Posix way to do it */
#if defined(O_NONBLOCK)
if (-1 == (flags = fcntl(fd, F_GETFL, 0)))
flags = 0;
return fcntl(fd, F_SETFL, flags | O_NONBLOCK);
/* Otherwise, use the old way of doing it */
flags = 1;
return ioctl(fd, FIOBIO, &flags);


IoctlSocket(socket, FIONBIO, (char *) &val);


d   domain
t   type
p   protocol
n   name
nl  namelen
l   level
r   request
a   arg
o   optname
ov  optval
ol  optlen
m   msg
l   length
f   flags

socket(d,t,p)               ex. s=socket(domain, type, protocol)
bind(s,n,nl)                ex. success = bind(s, name, namelen)
connect(s,n,nl)             ex. success = connect(s, name, namelen)
send(s,m,l,f)               ex. nbytes = send(s, msg, len, flags)
getsockopt(s,l,o,ov,ol)     ex. success =  getsockopt(s, level, optname, optval, optlen)
IoctlSocket(d,r,a)          ex. value = IoctlSocket(fd, request, arg)

d   domain
t   type
p   protocol
n   name
nl  namelen
l   level
r   request
a   arg
o   optname
ov  optval
ol  optlen
m   msg
l   length
f   flags

inet_addr(c)                ex. addr = inet_addr(cp)
getnetent(),                ex. struct netent *getnetent(void);
getprotoent(),              ex. struct protoent *getprotoent(void);
getservent(),               ex. struct servent *getservent(void); 

the following tags are supported:


<title>Welcome to my site</title>
<meta name="description" content="">
<meta name"keywords" content=" , ,">

<frameset rows = ....>

<h1>You need to update your browser to one that supports frames!</h1>
You don't need a body at all unless you use the <noframes></noframes> tag. In all honesty you really should create a <noframes> section with nothing but navigation to the links of the rest of the page. There are still people out there who browse web sites without frames.