Stateless Protocol Vs Stateful Protocol

1. In stateless protocol there is no record of the state is saved at server end. Client
send request to the server and server response back according to current state. A
stateless server does not keeps state between connections. Therefore, when you send
a request to a stateless server, it does not create any objects that track information
regarding your requests. ex.UDP, HTTP etc.

2. On the other hand, in stateful protocol there is tight dependency between client
and server. If client send a request to the server then it expects some kind of response,
if it does not get any response then resend request. A stateful server keeps state of
connections. ex.FTP, Talnet.

3. Stateless Protocols differ from Stateful Protocols in the way information about
requests is maintained. HTTP is a Stateless Protocol. Stateless Protocols are light
because servers using them keep no information about completed transactions and
processes, when a client breaks a connection with a server running a Stateless
Protocol, no data has to be cleaned up or logged off. By not tracking state information,
there is less overhead on the server, so it can generally handle transactions speedily.
Differentiate between SMB / HTTP wrt stateful and stateless protocol also give
submission for changing HTTP behavior as of SMB.

4. SMB. The Server Message Block (SMB) is a stateful protocol. It is a network file
sharing protocol, and as implemented in Microsoft Windows is known as Microsoft SMB
Protocol. The set of message packets that defines a particular version of the protocol is
called a dialect. The Common Internet File System (CIFS) Protocol is a dialect of SMB.
Both SMB and CIFS are also available on VMS, several versions of Unix, and other
operating systems.

5. HTTP. Hyper Text Transfer Protocol is a stateless protocol, in other word the
server will forget everything related to client/browser state. Although web applications
have made it virtually look like stateful. A stateless protocol can be forced to behave as
if it were stateful. This can be accomplished if the server sends the state to the client,
and if the client to sends it back again to the server, every time. There are three ways
this may be accomplished in HTTP:

a. a) One is cookies, in which case the state is sent and returned in HTTP
headers.
b. b) The second is URL extension, in which case the state is sent as part of
the URL as response.
c. c) The third is "hidden form fields", in which the state is sent to the client
as part of the response, and returned to the server as part of a form's
hidden data.

Submission for changing HTTP behavior as of SMB

6. Scalability and High Availability. One of the major reasons why HTTP scales
so well is its Statelessness. Stateless protocol eases the replication concerns, as the
state itself doesn't need to be stored on the server.

7. Stateful protocols are logically heavy to implement in Internet reliably. Stateless

servers are also easily scalable, while for stateful servers scalablity is problematic.
Stateless request can be sent to any node, at any time, while with Stateful this is not a
case.
8. HTTP as Stateless protocol increases availability for stateless web applications,
which otherwise would be difficult or impossible to implement. If there is connection lost,
there is no state that is lost, simple request resend will resolve the problem. Stateless
requests are also cacheable.