Objective C data type

• int        (4bytes).                
• float     (4bytes).
• double  (8 bytes). 
• BOOL      (1 bytes).
• char      (1 bytes).

int  =  Integer number.
float = Single precision floating point.
double = Double precision floating point.
BOOL  = Boolean type data ( true / false ).
char  = A single character.

data type example

int number = 121;
float number2 = 1.231;
BOOL aDeer = YES;    [ YES | NO ]




4 bytes = 32 bits = 2^32   =      4.294.967.296  possible value.


-2.147.483.648     ----------------------------    2.147.483.648

with unsigned ( command to use only positive value, no negative! ) we can make it from

0   ----------------------------   4.294.967.296


example:   unsigned int positive_number;



**float and double cant use unsigned.

modifier

data type can use modifier.

• short
• long

example:  short int  ( cost 2 byte).
                 long int ( cost 8 byte).
                 long double (cost 16 byte).

introduction to socket

Here's my sockets tute:

The key point is this: a browser doesn't talk to a web server on port 80, cos that would be crowded. The browser knocks on the server's port 80 and says "I'd like to talk to you" and the server says "OK talk to this new random port number of mine e.g. number 12734".

Now let's suppose you have firefox and chrome both running on your laptop both looking at news.bbc.co.uk. How does the server know which browser is GETting when the laptop IP is the same? Answer: chrome and firefox both choose random local port numbers and quote them when they knock on the server's port 80.

Here's the same story with <API names> filled in:
1) Apache starts on bbc.co.uk and <bind>s to port 80. That requires root permission cos 80 is less that 1024. The effect is simply that no other process can <bind> to port 80 thereafter.
2) Apache calls <listen> which tells the system to expect people to knock on there
3) Apache enters a loop <accept>ing on port 80. <accept> blocks until a new client knocks (i.e. connects.)
4) Firefox wants to read the news so it <connect>s to bbc.co.uk at port 80 using a new random local socket number, say, 1234
5) Apache's <accept> returns with a lovely new socket containing a new server-side port number (12734) and the client's IP and 1234. The client has already been told 12734 and even acknowledged receiving that number, so both ends know both IPs and both port numbers.
6) Now, between these two random port numbers, the roles are symmetrical: anybody can <send> data to the other end or block in <recv> waiting for the other end to send something. Anybody can close the connection. Meanwhile, the server's 80 is waiting for a different cllient but that's irrelevant to our personal connection on these two random port numbers.

That was TCP. UDP is simpler. In UDP, you either <bind> to a local port number and block in <recvfrom> which tells you the senders IP and port when it returns, or you <sendto> some foreign IP/port. (You can <bind> before <sendto>ing if you're fussy about the sender port number.) There's no concept of a connection here. The packet might get through or get lost and the sender will never know unless the receiving application does something special to tell him. Sometimes this is what you want because it's more efficient and there might already be some higher level connection/acknowledgement system.

(Incidentally, if anybody tells you that UDP connections can't get through routers cos the router needs a TCP connection to do masquerading, they're lying.)

For more tutes, google for "berkeley sockets"

introduction to socket by 'adrian' quorve.