Seach in Techno Google

Sunday, February 17, 2008

hacker vs cracker

What is the difference between a hacker and a cracker?

According to The Jargon Lexicon, hackers are defined as the following:
[originally, someone who makes furniture with an axe] 1. A person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users, who prefer to learn only the minimum necessary. 2. One who programs enthusiastically (even obsessively) or who enjoys programming rather than just theorizing about programming. 3. A person capable of appreciating hack value. 4. A person who is good at programming quickly. 5. An expert at a particular program, or one who frequently does work using it or on it; as in `a Unix hacker'. (Definitions 1 through 5 are correlated, and people who fit them congregate.) 6. An expert or enthusiast of any kind. One might be an astronomy hacker, for example. 7. One who enjoys the intellectual challenge of creatively overcoming or circumventing limitations. 8. [deprecated] A malicious meddler who tries to discover sensitive information by poking around. Hence `password hacker', `network hacker'. The correct term for this sense is cracker.

Cracker is a person who breaks security on a system. The cracker is looked down upon in the hacker group. The crackers are usually more secretive and have small groups in which they share their knowledge although they like to refer to themselves as hackers. Crackers are potentially more harmful than the true hacker who just wants to know the workings of a system.

Why do hackers consider their work valuable?

Hackers believe that they are just exploring how programmable systems work and that they are not doing anything wrong as long as no theft, vandalism, or breach of confidentiality is broken. The hackers also believe that sharing information is good to do and very powerful. They do not see any harm in sharing resources with each other to gain access into unforbidden places as long as no damage is done.

Object-oriented Design

INTRODUCTION TO OBJECT-ORIENTED DESIGN PART 1 - ABSTRACTION

Up until now we've largely avoided discussing object-oriented design (OOD). This is a topic with a variety of methods put forward, and people tend to have strong views about it. But there are some useful general principles that can be stated, and we will present some of them in a series of articles.

The first point is perhaps the hardest one for newcomers to OOD to grasp. People will ask "How can I decide what classes my program should have in it?" The fundamental rule is that a class should represent some abstraction. For example, a Date class might represent calendar dates, an Integer class might deal with integers, and a Matrix class would represent mathematical matrices. So you need to ask "What kinds of entities does my application manipulate?"

Some examples of potential classes in different application areas would include:

        GUI/Graphics - Line, Circle, Window, TextArea, Button, Point

Statistics - Mean, ChiSquare, Correlation

Geography - River, Country, Sea, Continent

Another way of saying it would be this. Instead of viewing an application as something that performs steps A, B, and C, that is, looking at the program in terms of its functions, instead ask what types of objects and data the application manipulates. Instead of taking a function-oriented approach, take an object-oriented one.

One obvious question with identifying potential classes is what level of granularity to apply. For example, in C++ an "int" is a primitive type, that represents an abstraction of mathematical integers. Should int be a class in the usual C++ sense? Probably not, because a class implies certain kinds of overhead in speed and space and in user comprehension. It's interesting to note that Java(tm), a newer object-oriented language, also has int, but additionally supports a "wrapper" class called Integer that represents an integer value. In this way, an application can manipulate integers either as primitives or as classes.

Consider a slightly more ambiguous case. Suppose that you're writing a Date class, and you want to express the concept "day of week". Should this be a class of its own? Besides devising a class for this purpose, at least five other representations are possible:

        int dow : 3;  (bit field)

char dow;

short dow;

int dow;

enum Dow {SUN, MON, TUE, WED, THU, FRI, SAT};

The "right" choice in this case is probably the enumeration. It's a natural way of representing a limited domain of values

Direct use of primitive types for representation has its drawbacks. For example, if I choose to represent day of week as an integer, then what is meant by:

        int dow;

...

dow = 19;

The domain of the type is violated. As another example, C/C++ pointers are notorious for being misused and thereby introducing bugs into programs. A better choice in many cases is a higher-level abstraction like a string class, found in the C++ and Java standard libraries.

On the other end of the scale, it's also possible to have a class try to do too much, or to cover several disparate abstractions. For example, in statistics, it doesn't make sense to mix Mean and Correlation. These statistical methods have little in common. If you have a class "Statistics" with both of these in it, along with an add() member function to add new values, the result will be a mishmash. For example, for Mean, you need a stream of single values, whereas for Correlation, you need a sequence of (X,Y) pairs.

We will have more to say about OOD principles. A good book illustrating several object-oriented design principles is "Designing and Coding Reusable C++" by Martin Carroll and Margaret Ellis, published by Addison-Wesley.

INTRODUCTION TO OBJECT-ORIENTED DESIGN PART 2 - DATA ABSTRACTION

As we said in the previous issue, object-oriented design has many aspects to it, and a variety of strong views about which approach is "right". But there are some general techniques that are useful.

One of these, one that constitutes a whole design method in itself, is data abstraction. Simply stated, data abstraction refers to identifying key data types in an application, along with operations that are to be done on those types.

What does this mean in practice? Suppose that we are doing graphics of some sort, and are concerned with X,Y points on a screen. Now, at a low enough level, a point might be described via a couple of floating-point numbers X and Y. But with data abstraction, we define a type "Point" that will refer to a point, and we hide from the users of the type just how such a point is implemented. Instead of directly using X,Y values, we present Point as a distinct data type, along with some operations on it.

In the case of a Point type, two of those operations are (1) establishing a new Point instance, that describes an actual screen point, and (2) computing the distance between this point and another point.

If Point was written out as a C++ class, it might look like:

        class Point {
float x;
float y;
public:
Point(float, float);
float dist(const Point&);
};

We've declared a class Point with a couple of private data members. There is a constructor to create new object instances of Point, and a member function dist() to compute the distance between this point and another one.

Suppose that we instead implemented this as C code. We might have:

        struct Point {
float x;
float y;
};

typedef struct Point Point;

float Point_dist(Point*);

and so on.

The C approach will certainly work, so why all the fuss about data abstraction and C++? There are several reasons for the fuss. One is simply that data abstraction is a useful way of looking at the organization of a software program. Rather than decomposing a program in terms of its functional structure, we instead ask the question "What data types are we operating on, and what sorts of operations do we wish to do on them?"

With data abstraction, there is a distinction made between the representation of a type, and public operations on and behavior of that type. For example, I as a user of Point don't have to know or care that internally, a point is represented by a couple of floating-point numbers. Other choices might conceivably be doubles or longs or shorts. All I care about is the public behavior of the type.

In a similar vein, data abstraction allows for the formal manipulation of types in a mathematical sense. For example, suppose that we are dealing with screen points in the range 0-1000, typical of windowing systems today. And we are using the C approach, and say:

        Point p;

p.x = 125;
p.y = -59;

What does this mean? The domain of the type has been violated, by introduction of an invalid value for Y. This sort of invalid value can easily be screened out in a C++ constructor for Point. Without maintaining integrity of a type, it's hard to reason about the behavior of the type, for example, whether dist() really does compute the distance appropriately.

Also, if the representation of a type is hidden, it can be changed at a later time without affecting the users of the type.

As another simple example of data abstraction, consider designing a String class. In C, strings are implemented simply as character pointers, that is, of type "char*". Such pointers tend to be error prone, and we might desire a higher-level alternative.

In terms of the actual string representation, we obviously have to store the string's characters, and we also might want to store the string length separately from the actual characters.

Some of the operations on strings that we might want would include:

        - creating a String from a char*

- creating a String from another String

- retrieving a character at a given index

- retrieving the length

- searching for a pattern in a String

Given this very rough idea for a data type, we could write C++ code like so:

        class String {
char* str;
int len;
public:
String(const char*);
String(const String&);
char charAt(int) const;
int length() const;
int search(const String&) const;
};

and so on.

In medium-complexity applications, data abstraction can be used as a design technique by itself, building up a set of abstract types that can be used to structure a complete program. It can also be used as part of other design techniques. For example, in some application I might have a calendar date type, used to store the birthdate of a person in a personnel record. Data abstraction could be used to devise a Date type, independent of any other design techniques used in the application.

There is an excellent (but out of print) book on data abstraction, with the title "Abstraction and Specification in Program Development", by Barbara Liskov and John Guttag (published 1986 by MIT Press). Note also that data abstraction is only one part of object-oriented design and programming. Some languages (Modula-2, Ada 83) support data abstraction without being fully object-oriented.

INTRODUCTION TO OBJECT-ORIENTED DESIGN PART 3 - POLYMORPHISM

The example in the previous section illustrates another aspect of object-oriented design, that of polymorphism. This term means "many forms", and in the context that we are using refers to the ability to call member functions of many object types using the same interface.

The simplest C++ example of this would be:

        #include 

class A {
public:
virtual void f() {cout << "A::f" << endl;}
};

class B : public A {
public:
virtual void f() {cout << "B::f" << endl;}
};

int main()
{
B b;
A* ap = &b;

ap->f();

return 0;
}

which calls B::f(). That is, the base class pointer ap "really" points at a B object, and so B::f() is called.

This feature requires some run-time assistance to determine which type of object is really being manipulated, and which f() to call. One implementation approach uses a hidden pointer in each object instance, that points at a table of function pointers (a virtual table or vtbl), and dispatches accordingly.

Without language support for polymorphism, one would have to say something like:

        #include 

class A {
public:
int type;
A() {type = 1;}
void f() {cout << "A::f" << endl;}
};

class B : public A {
public:
B() {type = 2;}
void f() {cout << "B::f" << endl;}
};

int main()
{
B b;
A* ap = &b;

if (ap->type == 1)
ap->f();
else
((B*)ap)->f();

return 0;
}

that is, use an explicit type field. This is cumbersome.

The use of base/derived classes (superclasses and subclasses) in combination with polymorphic functions goes by the technical name of "object-oriented programming".

It's interesting to note that in Java, methods (functions) are by default polymorphic, and one has to specifically disable this feature by use of the "final", "private", or "static" keywords. In C++ the default goes the other way.

INTRODUCTION TO OBJECT-ORIENTED DESIGN PART 4 - DATA HIDING

Another quite basic principle of object-oriented design is to avoid exposing the private state of an object to the world. Earlier we talked about data abstraction, where a user-defined type is composed of data and operations on that data. For example, in C++ a type Date might represent a user-defined type for calendar dates, and operations would include comparing dates for equality, computing the number of days between two dates, and so on.

Suppose that in C++, a Date type looks like this:

        class Date {
public:
int m; // month 1-12
int d; // day 1-31
int y; // year 1800-1999
};

and I say:

        Date dt;

dt.m = 27;

What does this mean? Probably nothing good. So it would be better to rewrite this as:

        class Date {
int m;
int d;
int y;
public:
Date(int, int, int);
};

with a public constructor that will properly initialize a Date object.

In C++, data members of a class may be private (the default), protected (available to derived classes), or public (available to everyone).

A simple and useful technique for controlling access to the private state of an object is to define some member functions for setting and getting values:

        class A {
int x;
public:
void set_x(int i) {x = i;}
int get_x() {return x;}
};

These functions are inline and have little or no performance overhead.

In C++ there is another sort of hiding available, that offered by namespaces. Suppose that you have a program with some global data in it:

        int x[100];

and you use a C++ class library that also uses global data:

        double x = 12.34;

These names will clash when you attempt to link the program. A simple solution is to use namespaces:

        namespace Company1 {
int x[100];
}

namespace Company2 {
double x = 12.34;
}

and refer to the values as "Company1::x" and "Company2::x". Note that the Java language has no global variables, and similar usage to this example would involve static data defined in classes.

Data hiding is a simple but extremely important concept. Without it, it is difficult to reason about the behavior of an object, given that its state can be arbitrarily changed at any point.

INTRODUCTION TO OBJECT-ORIENTED DESIGN PART 5 - REPRESENTATION HIDING

In the last issue we talked about data hiding, where the internal state of an object is hidden from the user. We said that one reason for this hiding is so that the state can not be arbitrarily changed.

Another aspect of hiding concerns the representation of an object. For example, consider a class to handle a stack of integers:

        class Stack {
???
public:
void push(int);
int pop();
int top_of_stack();
};

It's pretty obvious what the public member functions should look like, but what about the representation? At least three representations could make sense. One would be a fixed-length array of ints, with an error given on overflow. Another would be a dynamic int array, that is grown as needed by means of new/delete. Yet a third approach would be to use a linked list of stack records. Each of these has advantages and disadvantages.

Suppose that the representation was exposed:

        class Stack {
public:
int vec[10];
int sp;
...
int top_of_stack();
};

and someone cheats by accessing top of stack as:

        obj.vec[obj.sp]

instead of:

        obj.top_of_stack()

This will work, until such time as the internal representation is changed to something else. At that point, this usage will be invalidated, and will not compile or will introduce subtle problems into a running program (what if I change the stack origin by 1?).

The point is simply that exposing the internal representation introduces a set of problems with program reliability and maintainability.

INTRODUCTION TO OBJECT-ORIENTED DESIGN PART 6 - EXTENSIBILITY

Thus far we've looked at object-oriented design in isolation, focusing on individual classes as abstractions of some real-world entity. But as you're probably already aware, C++ classes (and ones in other languages as well) can be extended by deriving subclasses from them. These classes add functionality to the base class.

Suppose that we have a class:

        class A {
private:
int x;
protected:
int y;
public:
int z;
};

The declarations of the members indicate that x is available only to member functions of the class itself, y is available to subclasses, and z is available to everyone.

How do we decide how to structure a class for extensibility? There are several aspects of this, one of them being the level of protection of individual members. There is not a single "right" answer to this question, but one approach is to ask how the class is likely to be used. For example, with a Date class:

        class Date {
private:
long repr; // days since 1/1/1800
};

it's unlikely that a derived class will need to directly access repr, because it's in an arcane format and because the Date class can supply a set of functions that will suffice to manipulate Dates. There is a steep learning curve in learning how to directly manipulate the underlying representation, and a consequent ability to mess things up by getting it wrong.

On the other hand, for a Tree class:

        class TreeNode {
protected:
TreeNode* left;
TreeNode* right;
int value;
public:
TreeNode(TreeNode*, TreeNode*, int);
};

making the internal pointers visible may make sense, to facilitate a derived class walking through the tree in an efficient manner.

It's useful to distinguish between developers, who may wish to extend a class, and end users. For example, with the Date class, the representation (number of days since 1/1/1800) is non-standard, and in a hard format to manipulate. So it makes sense to hide the representation completely. On the other hand, for TreeNode, with binary trees as a well-understood entity, giving a developer access to the representation may be a good idea.

There's quite a bit more to say about extensibility, which we will do in future issues.

INTRODUCTION TO OBJECT-ORIENTED DESIGN PART 7 - MORE ABOUT EXTENSIBILITY

In the last issue we started talking about extending the functionality of a base class via a derived class. Another aspect of this simply deals with the issue of how far to carry derivation. In other words, how many levels of derived classes make sense?

In theoretical terms, the answer is "an infinite number". That is, you can carefully design a set of classes, with each derived class adding some functionality to its base class. There is no obvious stopping point for this process.

In practical terms, however, deep class derivations create more problems than they solve. At some point, humans lose the ability to keep track of all the relationships. And there are some hidden performance issues, for example with constructors and destructors. The "empty" constructor for C in this example:

        #include 

class A {
public:
A() {cout << "A::A\n";}
~A() {cout << "A::~A\n";}
};

class B : public A {
public:
B() {cout << "B::B\n";}
~B() {cout << "B::~B\n";}
};

class C : public B {
public:
C() {cout << "C::C\n";}
~C() {cout << "C::~C\n";}
};

void f()
{
C c;
}

int main()
{
f();

return 0;
}

in fact causes the constructors for B and A to be called, and likewise for the destructor.

As a simple rule of thumb, I personally try to keep derivations to three levels or less. In other words, a base class, and a couple of levels of derived classes from it.

INTRODUCTION TO OBJECT-ORIENTED DESIGN PART 8 - A BOOK ON C++ DESIGN

In issue #027 the new edition of Bjarne Stroustrup's book "The C++ Programming Language" was mentioned. This book came out a few months ago, and contains about 100 pages on design using C++. It starts out by discussing design at an abstract level, and then moves on to cover specific design topics as they relate to C++. Recommended if you're interested in this topic.

INTRODUCTION TO OBJECT-ORIENTED DESIGN PART 9 - TEMPLATES VS. CLASSES

In previous issues we've looked at some of the aspects of template programming. One big issue that comes up with object-oriented design is when to implement polymorphism via a template (a parameterized class or function) in preference to using inheritance or a single class.

This is a hard question to answer, but there are several aspects of the issue that can be mentioned. Consider first the nature of the algorithm that is to be implemented. How generally applicable is the algorithm? For example, sorting is used everywhere, and a well-designed sort function template for fundamental or user-defined types would be very handy to have around.

On the other hand, consider strings. Strings of characters are very heavily used in programming languages. But what about strings of doubles? For example, does taking a substring of doubles from a string mean very much? In certain applications it might, but clearly this feature is not as generally useful as strings of characters.

On the other side of this same argument, if we want to implement an algorithm for a set of types, and some of those types are much more widely used than others (such as a string of chars), then template specializations offer a way to tune performance. For example, a string template might be defined via:

        template  class string { ... };

with a specialization for characters:

        class string { ... };

that is optimized. Of course, if strings of chars represent 99% of the use of the string template, then perhaps simply devising a string class would make more sense.

Another question to ask is whether all the types of interest fit cleanly into a single class hierarchy. For example, a hierarchy for a GUI window system might have:

        class Component { ... };

class Container : public Component { ... };

class Window : public Container { ... };

class Frame : public Window { ... };

That is, all types are in one hierarchy. Such a type hierarchy is often best managed via abstract classes and virtual functions, without the use of templates. Note that using virtual functions allows for access to runtime type information, whereas templates are more of a compile-time feature. Newsletter issues #024, #025, and #026 give some examples of the use of virtual functions and runtime type identification.

But sometimes templates might be useful even in a simple hierarchy such as this one. For example, a hierarchy of GUI classes might be parameterized based on the type of the underlying display device, such as a bit-mapped display, dumb terminal, or touch-screen.

Friday, February 15, 2008

difference between C and C++

1. INTRODUCTION
C proved very useful in running applications coded in assembly language because of its strengths like a simple compiler, lower access levels of memory, lower run time support and an efficient constructing language that was in sync with the hardware instructions. Another of its credits is that it is a highly portable (compatible with a variety of OS & Platforms) with very minimal source code changes required. Thus it has enabled remote operations & independence from the hardware. C is also compliant to a variety of standards, making it work with everything.

C++ is known as a mid-level language. Due to the fact that the C++ comprises of both high-level and low-level language features. Some of the adjectives used to describe C++ are static typed, free-form, multi-paradigm and supporting procedural programming.


2. Characteristics
C

Some of the important characteristics of C are as follows:
  1. Structured programming facilities
  2. Confirming to the ALGOL traditions
  3. Short circuit evaluation – usage of only one operand if the result can be determined with it alone
  4. Static typing system for avoiding unintended operations
  5. Value passed parameters with relevance to pointer value passing
  6. Heterogeneous data combination & manipulation
  7. Reserved keywords and free-format source text
  8. Larger number of compound operators, such as +=, ++
  9. Huge variable hiding capacity, though function definitions being non-nestable
  10. Character – integer usage similar to assembly language
  11. Low-level access to computer memory via machine addresses and typed pointers
  12. Function pointers allow rudimentary forms of closures & polymorphic runtime
  13. Pointer arithmetic defined Array indexing (secondary notion)
  14. Standardized processor for defining macros, including source code files & conditional compilations
  15. Complex Input/Output and mathematical functions with consistent delegation to library routines
  16. Syntax same as “B” (C’s predecessor) but different from ALGOL e.g.: { ... } replaced begin ... end, && and || replaced and & or, which
  17. While B used & and | in both meanings, C made them syntactically distinct from the bit-wise operators
  18. Similarities to Fortran e.g: the equal- sign for assignment (copying) & two consecutive equal-signs to test for equality (compare to EQ) or the equal-sign in BASIC)

Other unofficial features added with time were:

  1. void functions
  2. Functions returning struct or union types instead of pointers
  3. Assignments enabled for struct data types
  4. const qualifier to make an object read-only
  5. Enumerated types
  6. Creationg of tool to avoid the inherent problems of the language

Soon C became powerful enough to have the UNIX Kernel (written in a assembly language) re-written making it one of the first OS Kernels written in a language apart from the assembly languages.

C++

  1. C++ is designed to be a statically typed, general-purpose language that is as efficient and portable as C
  2. C++ is designed to directly and comprehensively support multiple programming styles (procedural programming, data abstraction, object-oriented programming, and generic programming)
  3. C++ is designed to give the programmer choice, even if this makes it possible for the programmer to choose incorrectly
  4. C++ is designed to be as compatible with C as possible, therefore providing a smooth transition from C
  5. C++ avoids features that are platform specific or not general purpose
  6. C++ does not incur overhead for features that are not used
  7. C++ is designed to function without a sophisticated programming environment

Polymorphism, one of the prominent qualities of C++, enablesmany implementations with a single interphase and for objects to act according to circumstances. C++ supports both static (compile-time) and dynamic (run-time) polymorphisms. Compile-time polymorphism does not allow for certain run-time decisions, while run-time polymorphism typically incurs a performance penalty. C++, though considered a superset of C, there exist a few differences causing some valid C codes to be invalid in C++ or to behave differently in C++. Issues like the C++ defining new keywords namely new & class, that are used as identifiers in C. C and C++ codes can be intermixed by declaring any C code that is to be called from/used in C++ with C linkage & by placing it within an extern "C" { /* C code */ } block.

3. Criticisms

Despite its popularity, C has been criticized for having desirable operations being too hard to achieve and undesirable operations being too easy to accidentally invoke thereby involving more programmer skill, experience, effort, and attention to detail than other programming languages for the safe & effective use of the language.

When object-oriented languages became popular, C++ was an extension of C that provided object-oriented capabilities with C++ originally implemented as a preprocessor -- source code was translated into C, and then compiled with a C compiler.

C++ being derived from C, also happens to inherit most of the criticisms leveled against C. But since the language is actually a composition of two different languages, along with the load of huge programs, often end up making the compilation huge and inappropriate in terms of pure size. When this problem is tried to be avoided, by disabling some of the fringe codes, it was again criticized for losing out on several important utilities. The creator of C++ also feels that C++ is justified to be a complex language since the modern day programming requirements have also increased in a huge manner when compared to the yesteryears.


4. Comparison by functions and all
Appeared in:19721985
Designed by:Dennis RitchieBjarne Stroustrup
Developed by:Dennis Ritchie & Bell LabsBjarne Stroustrup
Typing Discipline:Static, WeakStatic, Unsafe, Nominative
Major Implementations:GCC, MSVC, Borland C, Watcom CGNU Compiler Collection, Microsoft Visual C++, Borland C++ Builder
Paradigms:Imperative (procedural) systems implementation languageMulti-paradigm
Influenced by:B (BCPL,CPL), ALGOL 68, AssemblyC, Simula, Ada 83, ALGOL 68, CLU, ML
Influenced:awk, csh, C++, C#, Objective-C, BitC, D, Concurrent C, Java, JavaScript, Limbo, Perl, PHPAda 95, C#, Java, PHP, D, Aikido
OOP(Object Oriented Programming):NoYes-polymorphism and inheritance
Speed:C applications are faster to compile and execute than C++ applicationsC++ applications are generally slower at runtime, and are much slower to compile than C programs
Classes:Uses structures instead, hence more liberty to use internal design elementsUses classes and objects
Programming-include:use #includeuse #include
Programming-String type:Cannot use string type but declare it as an arraCan use string type
Programming-input /output:scanf for input;printf for outputcout<<>>







Take the C-quiz(50 questions)
i made 72% lets see urs.




Thursday, February 14, 2008

Interview questions for computer science students

About TCP/IP

What is TCP?

TCP (Transmission Control Protocol) is the main transport protocol utilized in IP networks.
The TCP protocol exists on the Transport Layer of the OSI Model.
The TCP protocol is a connection-oriented protocol which provides end-to-end reliability.
By connection-oriented, we mean that before two network nodes can communicate using TCP, they must first complete a handshaking protocol to create a connection.
When we say that TCP provides end-to-end reliability, we mean that TCP includes mechanisms for error detection and error correction between the source and the destination.
These properties of TCP are in contrast to UDP, which is connectionless and unreliable.
Higher layer protocols which utilize TCP include HTTP, SMTP, NNTP, FTP, telnet, SSH, and LDAP.

Diagram of the TCP Header

TCP Header Format
-----------------

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

UDP

(User Datagram Protocol) is one of the two main transport protocols utilized in IP networks.
The UDP protocol exists on the Transport Layer of the OSI Model.
The UDP protocol is an unreliable connectionless protocol.
When we say that UDP is unreliable, we mean that UDP does not provide mechanisms for error detection and error correction between the source and the destination. Because of this, UDP utilized bandwidth more efficiently than TCP. Applications which utilize UDP and which require reliable transport must provide their own error detection and correction mechanisms.
By connectionless, we mean that a network node can communicate with another network node using UDP without first negotiating any kind of handshaking or creating a connection. Because of this, UDP is very efficient for protocols that send small amounts of data at irregular intervals.
These properties of UDP are in contrast to TCP, which is connection-oriented and provides end-to-end reliability.
Higher layer protocols which utilize UDP include DNS, BOOTP, DHCP, SNMP, and RADIUS.

Diagram of the UDP Header

UDP Header Format
-----------------

0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| | |
| Length | Checksum |
+--------+--------+--------+--------+
| +
| data octets ... +
+-----------------------------------+

What are TCP/IP ports?

TCP and IP are two seperate protocols. IP (Internet Protocol) is a network layer protocol, while TCP (Transmission Control Protocol) is a transport layer protocol.
Every computer and network device attached to the Internet has at least one IP address. For example, the IP address of this web server is 66.37.153.81.
Then, within each of those IP addresses, each computer and network device will have a number of TCP ports. For example, the web server software on this web server responds on TCP port 80 and the mail server software on the same computer responds on TCP port 25.
In a non-technical sense, you can think of an IP address as the address of an office building and the TCP ports are individual offices within that building.

TCP Ports

TCP ports either originate connections or they receive connections. Any TCP port can originate a connection, and the port numbers for those are not important. TCP ports which receive connections, on the other hand, have to be assigned specific port numbers so that people and applications know where to look for them. For example, DNS answers on TCP port 53 and HTTP answers on TCP port 80.
Port numbers that are statically assigned are known as well known port numbers are are usually below 1,024. To see a list of well known TCP ports, read What port number is XXX on?.








What are the types of network hardware

The label network hardware is generally given to any piece of equipment with the task of moving data.
Common categories of network hardware include:
• Routers
• Switches
• Network Interface Cards

Routers
A router is a network device with interfaces in multiple networks whose task is to copy packets from one network to another.
Routers operate at Layer 3 of the OSI Model, the Network Layer.
A router will utilize one or more routing protocols to create a routing table.
The router will then use the information in its routing table to make intelligent decisions about what packets to copy to which interface.
This process is known as routing.
Routers are available with many interface types, such as Ethernet and DSL. Wireless routers support wireless interfaces, such as 802.11 (Wi-Fi).
Not all routers clearly fall into the category of network hardware. Routing software makes it possible to build a fully functional router out of a normal computer

Switches
A switch is a network device with multiple ports in one network whose task is to copy frames from one port to another.
Switches operate at Layer 2 of the OSI Model, the Data-Link Layer.
A switch stores the MAC Address of every device which is connected to it.
The switch will then evaluate every frame that passes through it. The switch will examine the destination MAC Address in each frame.
Based upon the destination MAC Address, the switch will then decide which port to copy the frame to.
If the switch does not recognize the MAC Address, it will not know which port to copy the frame to. When that happens, the switch will broadcast the frame to all of its ports.
Before switches became available, devices called hubs were used. Hubs were less intelligent netword devices that always copied all frames to all ports. By only copying frames to the destination ports, switches utilize network bandwidth much more effectively than hubs did.
Another piece of network hardware related to the switch is the Bridge. A Bridge is effectively a two-port switch. Because few users need a two-port switch, they are no longer manufactured.

Network Interface Cards
A network interface card is an expansion card which installs into a computer and enables that computer to physically connect to a local area network.
The most common form of network interface card in current use is the Ethernet card. Other types of network interface cards include wireless network interface cards and Token Ring network interface cards.
Other terms for network interface card include network adapter, network card and NIC.
Network interface cards are becoming rare, as most motherboards now include built-in network interfaces.

About OSI Model

OSI Model
The seven layers of the OSI model are:
Layer Name
7 Application
6 Presentation
5 Session
4 Transport
3 Network
2 Data Link
1 Physical

The easiest way to remember the layers of the OSI model is to use the handy mnemonic "All People Seem To Need Data Processing":
Layer Name Mnemonic
7 Application All6 Presentation People
5 Session Seem
4 Transport To
3 Network Need
2 Data Link Data
1 Physical Processing

The functions of the seven layers of the OSI model are:
Layer Seven of the OSI Model
The Application Layer of the OSI model is responsible for providing end-user services, such as file transfers, electronic messaging, e-mail, virtual terminal access, and network management. This is the layer with which the user interacts.
Layer Six of the OSI Model
The Presentation Layer of the OSI model is responsible for defining the syntax which two network hosts use to communicate. Encryption and compression should be Presentation Layer functions.
Layer Five of the OSI Model
The Session Layer of the OSI model is responsible for establishing process-to-process commnunication between networked hosts.
Layer Four of the OSI Model
The Transport Layer of the OSI model is responsible for delivering messages between networked hosts. The Transport Layer should be responsible for fragmentation and reassembly.
ayer Three of the OSI Model
The Network Layer of the OSI model is responsible for establishing paths for data transfer through the network. Routers operate at the Network Layer.
Layer Two of the OSI Model
The Data Link Layer of the OSI model is responsible for communications between adjacent network nodes. Hubs and switches operate at the Data Link Layer.
Layer One of the OSI Model
The Physical Layer of the OSI model is responsible for bit-level transmission between network nodes. The Physical Layer defines items such as: connector types, cable types, voltages, and pin-outs.

The OSI Model vs. The Real World

The most major difficulty with the OSI model is that is does not map well to the real world!
The OSI was created after many of todays protocols were already in production use. These existing protocols, such as TCP/IP, were designed and built around the needs of real users with real problems to solve. The OSI model was created by academicians for academic purposes.
The OSI model is a very poor standard, but it's the only well-recognized standard we have which describes networked applications.
The easiest way to deal with the OSI model is to map the real-world protocols to the model, as well as they can be mapped.
Layer Name Common Protocols
7 Application SSH, telnet, FTP
6 Presentation HTTP, SMTP, SNMP
5 Session RPC, Named Pipes, NETBIOS
4 Transport TCP, UDP
3 Network IP
2 Data Link Ethernet
1 Physical Cat-5

The difficulty with this approach is that there is no general agreement as to which layer of the OSI model to map any specific protocol. You could argue forever about what OSI model layer SSH maps to.
A much more accurate model of real-world networking is the TCP/IP model:
TCP/IP Model
Application Layer
Transport Layer
Internet Layer
Network Interface Layer
The most significant downside with the TCP/IP model is that if you reference it, fewer people will know what you are talking about!