TweetFollow Us on Twitter

OPENSTEP Sockets

Volume Number: 13 (1997)
Issue Number: 7
Column Tag: Rhapsody

OPENSTEP Sockets

by Jason Proctor, BroadQuest, Inc.

Network programming in the brave new world of BSD Sockets, a networking interface under Rhapsody

Welcome to the Pleasure Dome

The Macintosh is about to take a large step into a brave new world. It's not quite the brave new world you or I expected or perhaps wanted, but it's going to happen nevertheless. Despite Apple's assurances to the contrary, I expect the first manifestation of the next-generation Macintosh OS to bear more resemblance to NEXTSTEP than to the current MacOS. Hence, it's a fair bet that we'll be getting unix-style networking. Indeed, a large clue has appeared with the news that Open Transport is on the list of projects that Apple is no longer continuing to develop.

I've been doing networking stuff for a good while, for MacOS and NEXTSTEP as well as other environments; so, it seemed a good idea (at the time) to write an article explaining how to use the new (actually rather old) APIs to do useful things.

Assumed Knowledge

The purpose of this article is to describe in detail the BSD sockets API, rather than the ins and outs of TCP/IP. Hence, I'll assume you've done a fair bit of network hacking before. You should be comfortable with IP addresses and port numbers, binding and connecting, and that kind of thing.

What's in this article

To start with, I'll describe a few major things that are different between the good old Mac APIs we're used to and the even older BSD sockets APIs you're probably going to have to get used to. I'll then provide a library of routines that make dealing with the socket library a touch easier, and finally I'll use the library to construct a simple server application.

Differences Between MacOS and BSD Sockets

Synchronicity

MacTCP, and to a lesser extent OT, were developed for the MacOS environment, which is essentially co-operatively scheduled. Hence, making synchronous I/O calls is a bad idea. Establishing a connection to a slow or distant site could take a good few seconds, during which time the machine can not respond to any user action. For this reason, these calls normally should be called asynchronously with one of a variety of strategies used to detect and respond to completion. It's beyond the scope of this article to go into those strategies, but suffice it to say that they boil down to completion routine chaining, checking during idle time, or using a Thread Manager thread to spin in a yielding loop.

In complete contrast however, the socket library was initially developed for Berkeley unix, a pre-emptively scheduled environment, and therefore synchronous calls are the norm. Indeed, there are no well-developed asynchronous facilities such as you would find under MacOS, because there is generally no need for them. Provided Rhapsody delivers on its pre-emptive multitasking promise, we can all use synchronous calls and get away with it.

Of course, that's not to say that there aren't any asynchronous facilities at all. Whilst being universally panned for having a dearth of industrial-grade real-time features, unix does provide signals as a means of being informed when something happens.

Portability

Hitherto, Mac developers have not had to consider portability issues when writing MacTCP or Open Transport code. Code written to these APIs is not going much further than MacOS, even though OT is loosely based on the XTI standard.

In contrast again, the socket library has been ported to many different environments, and one should always write socket code to be portable. One never knows when one might want to take one's precious code to unix, or anywhere else for that matter. Fortunately however, we only have one major portability concern to worry about -- the socket library expects all its IP addresses and port numbers in network (i.e., big-endian) format. By virtue of being initially hosted on the 68k processor, MacOS has its bytes the correct way round, which is why we haven't had to worry about it until now.

So, look out for the convertor routines in the code samples. I've illustrated their use with comments.

Protocol Independence

The socket library was designed with a certain degree of protocol independence in mind. This manifests in the API as socket calls taking several configuration parameters, and as other calls, if appropriate, taking pointers to generic address structures -- pointers to protocol-specific address structures must be cast appropriately.

However, implementing new transport protocols (such as UDP and TCP) generally means writing kernel servers, not a trivial task, and the competing XTI standard (on which OT is based) provides a slightly better interface for alternative protocols, hence other protocols which use the sockets interface are rare.

One extra protocol is normally available under standard BSD sockets, that of unix domain sockets. Although certain unix systems use these for IPC, they're generally used by normal people about as often as PowerTalk, so I won't reference them further. Details are available in the unix manual pages.

Network API Concepts

The BSD socket library API calls are substantially different to MacTCP and, to a lesser extent, OT, but the actual concepts one deals with are similar, as at the end of the day it's all just TCP/IP. Hence, anyone used to sockets, ports, connections, and the difference between stream-based and datagram-based communication will be off to a flying start. Basically you just do this:
  • Open a socket.
  • Bind to a port.
  • Establish a connection (optional for best-effort datagram-based service).
  • Send and receive some data.
  • Shut down the connection gracefully.

Making the Transition

We're all engineers, aren't we? On to the code.

Step 0: Dealing with IP Addresses

As previously indicated, the socket library requires its IP number and port values in network (that is, big-endian) format. It's easy to forget to convert backwards and forwards all the time. Also, the IP address structure is rather arcane, so a convenient way of accessing that structure is a big help. So, I use the following routines to make dealing with the socket address structure a touch more convenient.

Listing 1: SocketCalls.c

SetAddress
This routine configures an internet address structure from the passed in
IP number and port number parameters.

/* assumption: sizeof(long) == sizeof(IP address) */
/* this is not true for IPv6 */
void
SetAddress (struct sockaddr_in *aAddress,
  unsigned long aIPNumber, unsigned short aPort)
{
  /* set address family */
  aAddress->sin_family = PF_INET;
  /* IP number is assumed to be in network format */
  /* this is because IP numbers are rarely constructed manually */
  /* and are normally obtained via name lookup calls, etc */
  aAddress->sin_addr.S_un.S_addr = aIPNumber;
  /* port number is assumed to be in host format */
  aAddress->sin_port = htons (aPort);
}

GetAddress
This routine configures an internet address structure from the passed in
IP number and port number parameters.

/* assumption: sizeof(long) == sizeof(IP address) */
/* this is not true for IPv6 */
void
GetAddress (struct sockaddr_in *aAddress,
  unsigned long *aIPNumber, unsigned short *aPortNumber)
{
  /* the IP number is returned in network format */
  *aIPNumber = aAddress->sin_addr.S_un.S_addr;
  /* the port number is returned in host format */
  *aPortNumber = ntohs (aAddress->sin_port);
}

Step 1: Opening A Socket

To do anything, you must open a socket and tell the socket library what kind of communication you're ultimately going to be doing. When writing to the socket library, you call socket() and supply the appropriate arguments.

The socket() call takes three arguments -- the protocol family, the type of communication to be used, and the protocol within the protocol family. If we're intending to communicate TCP/IP, the first argument will always be PF_INET, signifying the internet domain protocol family. The second argument will be SOCK_STREAM or SOCK_DGRAM, according to whether we will be communicating via streams or datagrams. The third argument will be IPPROTO_TCP or IPPROTO_UDP, according to whether we will be communicating with the TCP or UDP protocol.

Note that the latter two arguments are of course linked. If you want to communicate using TCP, you must specify SOCK_STREAM as the second and IPPROTO_TCP as the third argument. For UDP, you must use SOCK_DGRAM as the second and IPPROTO_UDP as the third.

Other protocol types are available from the PF_INET family, such as the ICMP and RAW types, but they are rarely used by clients so I won't go into them here.

Listing 2: SocketCalls.c

OpenTCPSocket
This routine opens a socket which is configured for stream-based
communication over TCP.

int
OpenTCPSocket (int *aNewSocket)
{
  /* internet address family, stream-based, TCP */
  *aNewSocket = socket (PF_INET, SOCK_STREAM, IPPROTO_TCP);
  if (*aNewSocket == -1)
    return errno;
  else
    return 0;
}

OpenUDPSocket
This routine opens a socket which is configured for datagram-based
communication over UDP.

int
OpenUDPSocket (int *aNewSocket)
{
  /* internet address family, datagram-based, UDP */
  *aNewSocket = socket (PF_INET, SOCK_DGRAM, IPPROTO_UDP);
  if (*aNewSocket == -1)
    return errno;
  else
    return 0;
}

Step 2: Binding A Port

Unlike AppleTalk and IPX, TCP/IP exposes port numbers, rather than raw socket numbers. Hence it is necessary to associate our socket with a port number so that we can see and be seen on the network. As is usual with TCP/IP interfaces, we can either specify a port number or ask the socket library to give us the next unused one. Generally, servers would specify a well-known port number so that clients can find them. Under unix, and probably Rhapsody, the program would have to be running with root permission to bind to a port in the server range (less than 1024). This is to prevent user processes from masquerading as servers and snarfing people's passwords, amongst other nastiness.

The bind() call takes three parameters -- the number of the socket to be bound, the address to which the socket is to be bound, and the size of the address parameter. Note that the address parameter usually has an address member of zero, signifying the local IP address of the machine, however this need not be the case. Multiple IP addresses can be supported, and this is how web servers accomplish virtual hosting.

You'll notice that there's an extra call in the Bind() routine: the setsockopt() call. This call gives the TCP stack permission to bind to the same port each time. Otherwise, the stack imposes a 2 minute delay between binds to the same port. This delay is to guard against the following sequence of events:

  • Local endpoint opens a socket and binds to port n.
  • Remote endpoint establishes connection with port n.
  • Local endpoint disconnects in a disorderly fashion; remote endpoint is not aware connection has been dropped.
  • Local endpoint opens another socket and binds to port n.
  • Remote endpoint sends packet to port n, believing previous connection is still up.
  • Local endpoint receives packet from previous connection.
  • This is bad.

Thankfully, this happens very rarely nowadays.

Listing 3: SocketCalls.c

Bind
This routine associates a port number with a socket which has been
opened via the socket() call. If the port number is zero, the next
available port number is allocated from dynamic port space (ie
outside the server port range).

int
Bind (int aSocket, struct sockaddr_in * aLocalAddress)
{
  int    on = 1;

  assert (aLocalAddress);
  /* say it's OK to reuse our address */
  setsockopt (aSocket, SOL_SOCKET, SO_REUSEADDR, &on, sizeof (on));
  if (bind (aSocket,
    (struct sockaddr *) aLocalAddress,
      sizeof (struct sockaddr_in)) == 0)
  {
    return 0;
  }
  else
  {
    return errno;
  }
}

Step 3: Establishing a Connection

Establishing a connection is mandatory only for reliable, stream-based communication. Within the TCP/IP family of protocols, at least at the network/transport layer, this means TCP. If only best-effort, datagram-based (that is UDP) communication is required, connecting is not required, although if connect() is called on a UDP socket, this fixes the source and destination for further communication. This can be handy if you want to use unicast UDP but don't want to validate that the remote address is correct each time you receive a packet.

Connections are initiated via the connect() call. This takes three parameters -- the local socket number (which must be bound to a port), the address of the remote endpoint to connect to, and the size of the address parameter.

Listing 4: SocketCalls.c

Connect
This routine initiates a connection with the remote address. For
TCP sockets, this actually negotiates a connection. For UDP sockets,
it simply fixes the remote address.

int
Connect (int aSocket, struct sockaddr_in *aRemoteAddress)
{
  assert (aRemoteAddress);

  if (connect (aSocket, (struct sockaddr *) aRemoteAddress,
    sizeof (struct sockaddr_in)) == 0)
  {
    return 0;
  }
  else
  {
    return errno;
  }
}

Listening for incoming connections is accomplished with the listen() call, and accepting with the accept() call.

The listen() call takes two arguments -- the local socket number, which must be bound to a port, and a number signifying the "queue length". The latter is simply how many incoming connections can be held unaccepted -- any more are refused. Generally, you would want to tailor this number according to how many requests you are serving in a given time period.

The accept() call takes three arguments -- the local socket number, which must be bound to a port, a pointer to an address structure, and a pointer to an integer which is initialized to the size of the address structure. The address structure and size argument are filled in with the address of the endpoint initiating the connection.

Note that the accept() call returns a new socket, which is the connected socket over which all data transfer should be done. The original socket is dedicated to waiting for incoming connections, and should not be used for any data transfer. In this way, there is always a socket waiting for an incoming connection, and incoming connect requests cannot be lost.

Listing 5: SocketCalls.c

Accept
This routine listens for an incoming TCP connection.

int
Accept (int aSocket, struct sockaddr_in *aRemoteAddress,
  int aQueueLength, int *aNewSocket)
{
  int    addressLength;

  assert (aRemoteAddress);
  assert (aNewSocket);

  /* listen() is included here for clarity */
  /* technically, one must only call listen() once */
  if (listen (aSocket, aQueueLength) == 0)
  {
    addressLength = sizeof (struct sockaddr_in);

    *aNewSocket = accept (aSocket,
      (struct sockaddr *) aRemoteAddress,
        &addressLength);

    if (*aNewSocket > 0)
      return 0;
  }
  
  return errno;
}

Step 4: Sending and Receiving Data

Sending and receiving data can be as straightforward as unix file I/O, providing the socket is connected and no special options have to be set on the data to be sent. Normal unix read() and write() work just fine. However, the socket library does of course provide primitives for sending and receiving data in all cases, and clients generally use those.

The calls are split into two groups, for connected and unconnected sockets. For connected sockets, the send() and recv() calls are essentially the same as write() and read(), except that an additional flags parameter provides a mechanism for associating special options with the data. It's beyond the scope of this article to go into the options, but unix manual pages can provide full details.

For unconnected (that is, UDP) sockets, the calls are similar, but with the addition of separate destination (for sendto()) and source (for recvfrom()) parameters, and associated address size parameters. You must specify the destination for a send on an unconnected socket, and provide space for the source of a packet received on an unconnected socket.

Listing 6: SocketCalls.c

Send
This routine sends the passed-in chunk of data to the other end of
the connection. For unconnected UDP sockets, see SendTo().

int
Send (int aSocket, void *aData, int aLength)
{
  assert (aData);
  assert (aLength);
  if (send (aSocket, aData, aLength, 0) == aLength)
    return 0;
  else
    return errno;
}


SendTo
This routine sends the passed-in chunk of data to the specified address
and port. The socket must be unconnected.

int
SendTo (int aSocket, void *aData, int aLength,
  struct sockaddr_in *aDestination)
{
  assert (aData);
  assert (aLength);
  assert (aDestination);
  if (sendto (aSocket, aData, aLength, 0,
    (struct sockaddr *) aDestination,
      sizeof (struct sockaddr_in)) == 0)
  {
    return 0;
  }
  else
  {
    return errno;
  }
}


Receive
This routine receives data from the other end of a connection, up to
the amount specified in the parameters. For reception on unconnected
UDP sockets, see ReceiveFrom().

int
Receive (int aSocket, void *aData, int *aLength)
{
  int  cc;

  assert (aData);
  assert (aLength);
  cc = recv (aSocket, aData, *aLength, 0);
  if (cc >= 0)
  {
    /* note that zero receive generally means orderly shutdown at the other end */
    *aLength = cc;
    return 0;
  }
  else
  {
    *aLength = 0;
    return errno;
  }
}


ReceiveFrom
This routine receives data from an unconnected UDP port.

int
ReceiveFrom
  (int aSocket, void *aData, int *aLength,
    struct sockaddr_in *aSource)
{
  int    cc;
  int    addressLength;

  assert (aData);
  assert (aLength);
  assert (aSource);

  addressLength = sizeof (struct sockaddr_in);

  cc = recvfrom (aSocket, aData, *aLength, 0,
    (struct sockaddr *) aSource, &addressLength);

  if (cc >= 0)
  {
    *aLength = cc;
    return 0;
  }
  else
  {
    *aLength = 0;
    return errno;
  }
}

Step 5: Shutting Down the Connection Gracefully

TCP clients are happiest if they notify one another when a connection is going down. Amongst other benefits, graceful disconnection means fewer packets transmitted on dead connections, which is a good thing for everyone.

Under MacTCP and OT, orderly disconnection is a rather messy process involving closing the local end and then waiting for the remote to close its end. There are a few different situations to survive and most hackers will probably say this is the gnarliest bit of code for these APIs.

Orderly disconnection under sockets however couldn't be easier, largely because the protocol stack handles all the nastiness for you. The shutdown() call takes two parameters -- the socket to be affected and an integer specifying which ends of the connection to close. If the second parameter is zero, further reception is prevented (that is, the remote end is closed); if it is 1, further transmission is prevented (that is, the local end is closed); if it is 2, both ends are closed and the connection is torn down.

Listing 7: SocketCalls.c

Disconnect
This routine disconnects both ends of a connected socket.

int
Disconnect (int aSocket)
{

  if (shutdown (aSocket, 2) == 0)
    return 0;
  else
    return errno;
}

Domain Name Lookups

Domain name lookups are generally performed by one routine -- gethostbyname(). This call takes one parameter -- a C string (that is, zero terminated) specifying the name to look up. It returns a pointer to a static structure describing the host, with IP addresses and other names that host might have, amongst other details.

The kicker with the structure returned by gethostbyname() is that it contains a list of pointers to IP addresses, rather than copies of them. This is to enable a certain amount of address size independence. Hence one must copy the addresses out of the structure. I've lost count of the number of times I've forgotten this detail and sat there wondering why the addresses I'm getting back are complete crap.

Listing 8: SocketCalls.c

LookupName
This routine looks up the passed name and places the first matching
address in the passed output parameter.

int
LookupName
  (char *aHostName, struct sockaddr_in *aAddress)
{
  struct hostent  *hp;

  assert (aHostName);
  assert (aAddress);

  hp = gethostbyname (aHostName);

  if (hp)
  {
    /* size of address returned is protocol-dependent */
    memcpy (&aAddress->sin_addr, hp->h_addr_list [0],
      hp->h_length);
    return 0;
  }
  else
  {
    return h_errno;
  }
}

Building a Document Server

This is a simple HTTP-type document server that loops accepting TCP connections on a user-specified port number (defaulted to 8000). When the program successfully accepts an incoming connection, it expects a file name followed by a carriage return or line feed. The server then attempts to open the file and send the contents down the TCP connection. Server-side errors are signified by closing the connection before any content is sent.

Listing 9: DocumentServer.c

main
Mainline for the document server.

#include <errno.h>        /* for errno extern */
#include <fcntl.h>        /* for file open mode */
#include <libc.h>          /* for generic ANSI stuff */
#include <netdb.h>        /* for lookups */
#include <netinet/in.h>    /* for PF_INET stuff */
#include <stdio.h>        /* for printf() */
#include <sys/socket.h>    /* for socket API */

#define kDefaultPortNumber  8000

#define assert(x) if(!(x)) \
  printf("%s,%d: assertion failure\n", __FILE__, __LINE__);

int
main (int argc, char *argv [])
{
  char                  buffer [1024];
  int                  acceptingSocket;
  int                  amountRead;
  int                  amountReceived;
  int                  dataSocket;
  int                  fd;
  int                  i;
  int                  portNumber;
  struct sockaddr_in    local;
  struct sockaddr_in    remote;

  /* make a socket */
  if (OpenTCPSocket (&acceptingSocket) != 0)
  {
    perror ("socket");
    exit (1);
  }

  /* allow setting of port number by arguments */
  if (argc > 1)
  {
    portNumber = atoi (argv [1]);

    if (portNumber == 0)

      portNumber = kDefaultPortNumber;
  }
  else
  {
    portNumber = kDefaultPortNumber;
  }

  printf ("listening on port %d \n", portNumber);

  /* set up our bind address */
  /* note the address is zero, for the local address */
  /* the port number is expected in host format */
  SetAddress (&local, 0, portNumber);
  if (Bind (acceptingSocket, &local) != 0)
  {
    perror ("bind");
    exit (1);
  }

  /* loop accepting incoming connections */
  while (Accept(acceptingSocket, &remote, 5, &dataSocket)==0)
  {
    amountReceived = sizeof (buffer);

    if (Receive (dataSocket, buffer, &amountReceived) == 0)
    {
      /* assumption: we receive the file name in one chunk */
      for (i = 0; i < amountReceived; i++)
      {

        if (buffer [i] == '\r' || buffer [i] == '\n')
        {
          buffer [i] = 0;
          break;
        }
      }

      if (i == amountReceived)
      {
        /* we didn't find a CR/LF in the chunk */
      }
      else
      {
        /* open up the file */
        fd = open (buffer, O_RDONLY);

        if (fd == -1)
        {
          /* couldn't open the file */
          perror (buffer);
        }
        else
        {
          do
          {
            /* read a chunk from the file */
            amountRead = read (fd, buffer, sizeof (buffer));

            if (amountRead > 0)
            {
              /* send what we got down the connection */

              if (Send
                (dataSocket, buffer, amountRead) != 0)
              {
                /* the initiator has probably closed */
                perror ("send");
                break;
              }
            }
          }
          while (amountRead == sizeof (buffer));
        }
      }
    }
    else
    {
      /* couldn't read from the connection */
      /* the remote end has probably closed */
      perror ("recv");
    }

    Disconnect (dataSocket);
  }

  perror ("accept");

  exit (1);

  /* NOTREACHED */
}

Further Reading

Any unix manual pages will give you copious information on the socket library. Simply type "man socket" at any available shell prompt. Unfortunately however, the man pages have a tendency to provide amazing detail without actually telling you how to do anything. When I first got into networking, the unix manual pages misled me so much that I actually thought AppleTalk was easier to use than sockets. Nothing could be further from the truth.

There are several good books on the socket library in particular and TCP/IP in general. Lots of people learned their TCP/IP from Douglas Comer's seminal work "Internetworking with TCP/IP", in at least three volumes with lots of quality info.

Also worth a look is the Addison-Wesley series "Illustrating TCP/IP", in at least three thicker volumes. These live up to the high standard maintained by A-W's Professional Computing Series.


Jason Proctor is Minister of Ideology for BroadQuest Inc, a startup doing cool things with the network. In past lives he has emulated PCs for Insignia, done the networking for the cool but ill-fated Software Ventures web browser, and worked on reliable multicasting for GlobalCast. Even though he finds himself writing Unix code more often than he'd like, he considers himself a Macintosh bigot.

 

Community Search:
MacTech Search:

Software Updates via MacUpdate

BBEdit 11.0.3 - Powerful text and HTML e...
BBEdit is the leading professional HTML and text editor for the Mac. Specifically crafted in response to the needs of Web authors and software developers, this award-winning product provides a... Read more
Microsoft Office Preview 15.8 - Popular...
Welcome to the new and modern Microsoft Office for Mac. You will receive regular updates automatically until the official release in the second half of 2015. With the redesigned Ribbon and your... Read more
Yosemite Cache Cleaner 9.0.5 - Clear cac...
Yosemite Cache Cleaner is an award-winning general purpose tool for OS X. YCC makes system maintenance simple with an easy point-and-click interface to many OS X functions. Novice and expert users... Read more
ExpanDrive 4.3.2 - Access cloud storage...
ExpanDrive builds cloud storage in every application, acts just like a USB drive plugged into your Mac. With ExpanDrive, you can securely access any remote file server directly from the Finder or... Read more
RapidWeaver 6.0.8 - Create template-base...
RapidWeaver is a next-generation Web design application to help you easily create professional-looking Web sites in minutes. No knowledge of complex code is required, RapidWeaver will take care of... Read more
Artlantis Studio 5.1.2.7 - 3D rendering...
Artlantis Studio is a unique and ideal tool for performing very high resolution rendering easily and in real time. The new FastRadiosity engine now lets you compute images in radiosity-even in... Read more
MacUpdate Desktop 6.0.5 - Search and ins...
MacUpdate Desktop 6 brings seamless 1-click installs and version updates to your Mac. With a free MacUpdate account and MacUpdate Desktop 6, Mac users can now install almost any Mac app on macupdate.... Read more
BitTorrent Sync 2.0.82 - Sync files secu...
BitTorrent Sync allows you to sync unlimited files between your own devices, or share a folder with friends and family to automatically sync anything. File transfers are encrypted. Your information... Read more
Google Drive 1.20 - File backup and shar...
Google Drive is a place where you can create, share, collaborate, and keep all of your stuff. Whether you're working with a friend on a joint research project, planning a wedding with your fiancé, or... Read more
Simon 4.0.3 - Monitor changes and crashe...
Simon monitors websites and alerts you of crashes and changes. Select pages to monitor, choose your alert options, and customize your settings. Simon does the rest. Keep a watchful eye on your... Read more

New Publisher Allstar Games Heads West w...
Allstar Games has announced its first mobile title designed for western audiences, Allstar Heroes. The game will be a massive online battle arena (MOBA) that offers dozens of heroes for you to collect and pit against your opponents. As each hero has... | Read more »
RAD Boarding Review
RAD Boarding Review By Jennifer Allen on March 5th, 2015 Our Rating: :: NEARLY RADUniversal App - Designed for iPhone and iPad RAD Boarding isn’t quite one of the greats, but it has potential.   | Read more »
Presenting the International Mobile Gami...
11th Annual International Mobile Gaming Awards ceremony, hosted by actress Allison Haislip, gathered mobile game developers and publishers from around the world. They chose 13 winners out of the 93 nominations. British studio USTWO won the the Grand... | Read more »
AG Drive Review
AG Drive Review By Tre Lawrence on March 5th, 2015 Our Rating: :: FUTURISTIC STREET RACING.Universal App - Designed for iPhone and iPad Futuristic racing… interstellar style.   | Read more »
GDC 2015 – Nightmare Guardians is an Int...
GDC 2015 – Nightmare Guardians is an Interesting Hybrid of MOBA and Lane Defense Posted by Rob Rich on March 5th, 2015 [ permalink ] I have to say that lane defense (i.e. | Read more »
Overkill 3 Review
Overkill 3 Review By Tre Lawrence on March 5th, 2015 Our Rating: :: WHO'S NEXT?Universal App - Designed for iPhone and iPad Cover system gameplay in the third-person.   Developer: Craneballs Price: Free Version Reviewed: 1.1.6... | Read more »
Warner Bros. Interactive Entertainment A...
Warner Bros. has some exciting games coming down the pipe! | Read more »
GDC 2015 – Star Trek Timelines will Prob...
GDC 2015 – Star Trek Timelines will Probably Make Your Inner Trekkie Squeal With Glee Posted by Rob Rich on March 4th, 2015 [ permalink ] Any popular fictional universe has its fair share of fan fiction – where belo | Read more »
Protect Yourself from an Onslaught of Ca...
Surprise Attack Games has announced a Cat-astrophic new physics puzzler called Fort Meow! In the game, a young girl named Nia finds her grandfather’s journal which triggers an all mighty feline attack! Why do the cats want the journal? Who knows,... | Read more »
GDC 2015 – Jelly Reef will be Game Oven’...
GDC 2015 – Jelly Reef will be Game Oven’s Last Hurrah, and it Seems like a Good Note to Go Out on Posted by Rob Rich on March 4th, 2015 [ permalink ] It’s sad knowing that Game Oven ( | Read more »

Price Scanner via MacPrices.net

Roundup of MacBook Air sale prices, models up...
B&H Photo has MacBook Airs on sale for up to $100 off MSRP. Shipping is free, and B&H charges NY sales tax only: - 11″ 128GB MacBook Air: $799 100 off MSRP - 11″ 256GB MacBook Air: $999 $100... Read more
New Firstrade Mobile App Enables On-The-Go Tr...
Firstrade Securities Inc. has announced its new mobile app, which gives investors immediate access to the company’s trading platform on all mobile devices. The app was developed in-house and was... Read more
Sonnet Introduces USB 3.0 + eSATA Thunderbolt...
Sonnet has announced the launch of its new USB 3.0 + eSATA Thunderbolt Adapter for easy connectivity to USB 3.0 devices and eSATA storage, and USB 3.0 + Gigabit Ethernet Thunderbolt Adapter for easy... Read more
Apple restocks refurbished 27-inch 5K iMacs f...
The Apple Store has restocked Apple Certified Refurbished 27″ 3.5GHz 5K iMacs for $2119 including free shipping. Their price is $380 off the cost of new models, and it’s the lowest price available... Read more
Free Clean Reader Mobile App Hides Swear Word...
The new Clean Reader app, now available in the Apple App Store and Google Play, delivers the opportunity of reading any book without being exposed to profanity. By selecting how clean they want their... Read more
Kinsa Launches “Groups” App to Monitor Illnes...
Kinsa, makers of the first FDA approved app-enabled smartphone thermometer thst won the 2013 Cleveland Clinic Medical Innovation Grand Prize and recently appeared in Apple’s “Parenthood” TV... Read more
iPad: A More Positive Outlook – The ‘Book Mys...
It’s good to hear someone saying positive things about the iPad. I’ve been trying to bend my mind around how Apple’s tablet could have gone from zero to bestselling personal computing device on the... Read more
Mac Pros on sale for up to $279 off MSRP
Amazon has Mac Pros in stock and on sale for up to $279 off MSRP. Shipping is free: - 4-Core Mac Pro: $2725.87, $273 off MSRP (9%) - 6-Core Mac Pro: $3719.99, $279 off MSRP (7%) Read more
Sale! 13-inch Retina MacBook Pros for up to $...
B&H Photo has 13″ Retina MacBook Pros on sale for up to $205 off MSRP. Shipping is free, and B&H charges NY sales tax only: - 13″ 2.6GHz/128GB Retina MacBook Pro: $1219.99 save $80 - 13″ 2.... Read more
Another Tranche Of IBM MobileFirst For iOS Ap...
IBM has announced the next expansion phase for  its IBM MobileFirst for iOS portfolio, with a troika of new apps to address key priorities for the Banking and Financial Services, Airline and Retail... Read more

Jobs Board

*Apple* Retail - Multiple Positions (US) - A...
Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, you're also the Read more
*Apple* Solutions Consultant - Retail Sales...
**Job Summary** As an Apple Solutions Consultant (ASC) you are the link between our customers and our products. Your role is to drive the Apple business in a retail Read more
Position Opening at *Apple* - Apple (United...
…Summary** As a Specialist, you help create the energy and excitement around Apple products, providing the right solutions and getting products into customers' hands. You Read more
Position Opening at *Apple* - Apple (United...
**Job Summary** The Apple Store is a retail environment like no other - uniquely focused on delivering amazing customer experiences. As an Expert, you introduce people Read more
*Apple* Solutions Consultant - Retail Sales...
**Job Summary** As an Apple Solutions Consultant (ASC) you are the link between our customers and our products. Your role is to drive the Apple business in a retail Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.