Socket: 10.1 Domain-Specific Information: TCP/IP--GEOS Specific

GEOS SDK TechDocs

10 Domain-Specific Information

10.2 TCP/IP--Standard

The TCP/IP domain is a popular standard used for internet communications. The GEOS-specific version supports 32-bit port numbers. GEOS TCP/IP data may be transmitted via a regular TCP/IP network, though both the sending and receiving machines must support GEOS TCP/IP.

Domain Name:

"TCPIP_GEOS "

Port Numbers:

32-bit values.

Opaque Address Format:

This address will be either a TcpAccPntExtendedAddress ,a TcpOnlyExtendedAddress , or a TcpNonAccPntExtendedAddress .

TcpAccPntExtendedAddress: Use this structure when referring to an address identified by an access point ID number.

TcpOnlyExtendedAddress: Use this structure to identify a TCP address by its address instead of by its ID.

TcpNonAccPntExtendedAddress: Use this structure to identify a TCP address that is not a known access point. You will need to specify a link address (a phone number) as well as an IP address.

Notes:

• On some devices (including the Nokia 9000i Communicator), you cannot make a TCP/IP connection or send packets until the device has a "raw" connection to the network--a PPP connection. Calling SocketOpenDomainMedium() with the TCP medium creates a PPP connection. The modem will dial, and the machine will connect to the PPP server, but no TCP level packets will be sent. If the PPP connection is already made, this routine will return SE_NORMAL, just as if the connection had been just now made. If the modem is already in use, an SE_MEDIUM_BUSY error will be returned. Use the SocketCloseDomaninMedium() to hang up the phone when done.
• The Talk sample application shows how a device can make a raw PPP connection with the Internet Service Provider (ISP), getting the necessary information about the ISP from the built-in Access Point library. (Notice how the object AccpntControl is declared; notice the sample's TalkAddressClass handler for MSG_GEN_GUP_INTERACTION_COMMAND , which queries the AccessPointControl for the selected ISP and extracts the useful information about that ISP; finally, the MSG_CTP_CONNECT handler dials the phone to make the PPP connection.)

Code Display 23-2 Making the Raw TCP/IP Connection

Here we see three snippets of code from the Talk sample application
The AccessPointControl allows the user to choose an ISP:

@chunk char accpntMkr[] = "Access List";

@object AccessPointControlClass AccpntControl = {
	GI_states = GS_USABLE|GS_ENABLED;
	HINT_ACCESS_POINT_CONTROL_MINIMIZE_SIZE;
	ATTR_ACCESS_POINT_CONTROL_LIST_MONIKER = @accpntMkr; }

In @method TalkAddressClass, MSG_GEN_GUP_INTERACTION_COMMAND, we get information we'll need about the ISP

point = @call \
GeodeGetOptrNS(@AccpntControl)::MSG_ACCESS_POINT_CONTROL_GET_SELECTION();

/* store link info into address buffer */
rawAddress.UTA_link.TAPEA_linkSize = 3;
rawAddress.UTA_link.TAPEA_linkType = LT_ID;
rawAddress.UTA_link.TAPEA_accPntID = point;

/* the text of the address follows the link info */
alen = @call GeodeGetOptrNS(@IPText)::MSG_VIS_TEXT_GET_ALL_PTR( 
						(char *)&(rawAddress.UTA_ip[0]));

if (alen > MAX_IP_ADDR_STRING_LENGTH) FatalError(0);  /* too much text */

/* resolve the raw address into a SocketAddress */
theAddress.SA_addressSize = SocketResolve(theAddress.SA_domain,
					(byte *)(&rawAddress),
					sizeof(TcpAccPntExtendedAddress)+alen,
					(byte *)(&addressBuffer),
					MAX_ADDRESS_SIZE);

In MSG_CTP_CONNECT's handler, we make the PPP connection:

rval = SocketOpenDomainMedium((SocketAddress *) &theAddress, SOCKET_NO_TIMEOUT);

• TCP/IP only supports one byte of urgent data in a packet. If you send a multi-byte packet marked urgent, it will be divided into two packets (on the receiving side). For example, a 32-byte packet marked urgent would be broken up into a 31-byte normal packet and a one-byte urgent packet.

If you set the SSF_URGENT flag to SocketSend() when sending a multi-byte packet, the last byte of the packet will be marked urgent.

Recall that you can set the in-line option to specify that urgent data should be treated as normal data. In this case, urgent data will be treated as a normal 1-byte packet.

• If you're not familiar with TCP/IP, TCP/IP illustrated by W. Richard Stevens provides a good introduction.
  
  The TCP/IP standard is defined in a number of RFCs. The RFCs listed below may be of interest. If you research these documents, note that the first is an index to the others.
  
  1720 J. Postel, I. Architecture Board (IAB), "INTERNET OFFICIAL PROTOCOL STANDARDS", 11/23/1994. (Obsoletes RFC1610) (Obsoleted by RFC1780) (STD 1)
  
  1700 J. Reynolds, J. Postel, "ASSIGNED NUMBERS", 10/20/1994. (Obsoletes RFC1340)
  
  1122 R. Braden, "Requirements for Internet hosts - communication layers", 10/01/1989.
  
  1123 R. Braden, "Requirements for Internet hosts - application and support", 10/01/1989.
  
  0791 J. Postel, "Internet Protocol", 09/01/1981. (Obsoletes RFC0760)
  
  0950 J. Mogul, J. Postel, "Internet standard subnetting procedure", 08/01/1985.
  
  0919 J. Mogul, "Broadcasting Internet datagrams", 10/01/1984.
  
  0922 J. Mogul, "Broadcasting Internet datagrams in the presence of subnets", 10/01/1984.
  
  0792 J. Postel, "Internet Control Message Protocol", 09/01/1981. (Obsoletes RFC0777)
  
  0768 J. Postel, "User Datagram Protocol", 08/28/1980.
  
  0793 J. Postel, "Transmission Control Protocol", 09/01/1981. (Updates RFC0761)
  
  1034 P. Mockapetris, "Domain names - concepts and facilities", 11/01/1987. (Obsoletes RFC0973) (Updated by RFC1101)
  
  1035 P. Mockapetris, "Domain names - implementation and specification", 11/01/1987. (Obsoletes RFC0973) (Updated by RFC1348)
  
  0974 C. Partridge, "Mail routing and the domain system", 01/01/1986.
  
  1531 R. Droms, "Dynamic Host Configuration Protocol", 10/07/1993. (Obsoleted by RFC1541)
  
  1533 S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor Extensions", 10/08/1993. (Obsoletes RFC1497)
  
  1534 R. Droms, "Interoperation Between DHCP and BOOTP", 10/08/1993.
  
  1144 V. Jacobson, "Compressing TCP/IP headers for low-speed serial links", 02/01/1990.
  
  1547 D. Perkins, "Requirements for an Internet Standard Point-to-Point Protocol", 12/09/1993.
  
  1662 W. Simpson, "PPP in HDLC-like Framing", 07/21/1994. (Obsoletes RFC1549)
  
  1334 B. Lloyd, W. Simpson, "PPP Authentication Protocols", 10/20/1992.
  
  1661 W. Simpson, "The Point-to-Point Protocol (PPP)", 07/21/1994. (Obsoletes RFC1548)
  
  1570 W. Simpson, "PPP LCP Extensions", 01/11/1994. (Updates RFC1548)
  
  1663 D. Rand, "PPP Reliable Transmission", 07/21/1994.
  
  1332 PS G. McGregor, "The PPP Internet Protocol Control Protocol (IPCP)", 05/26/1992. (Obsoletes RFC1172)
• Some (16-bit) constants (defined in sockmisc.h ) are available with the port numbers for common TCP services:

#define  ECHO            7  /* TCP/UDP */
#define  DISCARD         9  /* TCP/UDP */
#define  FTP_DATA        20 /* TCP */
#define  FTP             21 /* TCP */
#define  TELNET_SERVER   23 /* TCP */
#define  NAME_SERVER     42 /* UDP */
#define  WHOIS           43 /* TCP */
#define  DOMAIN_SERVER   53 /* TCP/UDP */
#define  FINGER          79 /* TCP */

• The address data information with a SocketAddress structure takes the following form for the TCP domain:

typedef struct {
	word     TOEA_linkSize; 				/* 0 */
	byte    TOEA_ipAddr[4]; /* IP address */
}  TcpOnlyResolvedAddress;

A variation on this structure is used for storing the address information for a TCP access point address. Along with the address information, there are three bytes of information about the nature of the link: the first of these bytes should have value LT_ID, so that the driver will know that the next two bytes represent a link ID; the other two bytes should be the access point's ID.

typedef struct {
	word	TAPRA_linkSize; /* 3 */
	byte	TAPRA_linkType; /* LinkType (LT_ID) */
	word	TAPRA_accPntID;
	byte	  TAPRA_ipAddr[4]; /* IP address */
}  TcpAccPntResolvedAddress;

GEOS SDK TechDocs

10 Domain-Specific Information

10.2 TCP/IP--Standard