+ /**
+ * Create an instance of SGSocket.
+ *
+ * When calling the constructor you need to provide a host name, a
+ * port number, and a socket style. The convention used by the
+ * SGSocket class is that the server side listens and the client
+ * side sends. For a server socket, the host name should be
+ * empty. For a server, the port number is optional, if you do not
+ * specify a port, the system will assign one. For a client
+ * socket, you need to specify both a destination host and
+ * destination port. For both client and server sockets you must
+ * specify the socket type. Type must be either udp or tcp. Here's
+ * a quick breakdown of the major differences between UDP and TCP
+ * type sockets.
+ *
+ * TCP sockets are the type where you establish a connection and
+ * then can read and write to the socket from both ends. If one
+ * end of TCP socket connect quits, the other end will likely
+ * segfault if it doesn't take special precautions. But, the nice
+ * thing about TCP connections is that the underlying protocol
+ * guarantees that your message will get through. This imposes a
+ * certain performance overhead though on the communication
+ * because the protocol must resend failed messages. TCP sockets
+ * are good for sending periodic command/response type messages
+ * where performance isn't a big issues, but reliability is.
+ *
+ * UDP sockets on the other hand are a lower level protocol and
+ * don't have the same sort of connection as TCP sockets. With UDP
+ * sockets, the server end just sits and listens for incoming
+ * packets from anywhere. The client end sends it's message and
+ * forgets about it. It doesn't care if there isn't even a server
+ * out there listening and all the packets are getting
+ * lost. Although systems/networks usually do a pretty good job
+ * (statistically) of getting your UDP packets to their
+ * destination, there is no guarantee that any particular packet
+ * will make it. But, because of this low level implementation and
+ * lack of error checking, UDP packets are much faster and
+ * efficient. UDP packets are good for sending positional
+ * information to synchronize two applications. In this case, you
+ * want the information to arrive as quickly as possible, and if
+ * you lose a packet, you'd rather get new updated information
+ * rather than have the system waste time resending a packet that
+ * is becoming older and older with every retry.
+ * @param host name of host if direction is SG_IO_OUT or SG_IO_BI
+ * @param port port number if we care to choose one.
+ * @param style specify "udp" or "tcp"
+ */