How PeSIT works

This section provides a high level overview of how the PeSIT protocol works.

A PeSIT connection involves the following steps, in the indicated order, as each layer is dependent on the preceding step.

High level overview of connection layers


  1. Establish a network connection, such as TCP/IP in our example.
  2. Optionally secure the session using SSL/TLS (the handshake occurs).
  3. The PeSIT session starts.
    See File transfer phases in a PeSIT session for PeSIT session phases details.








Partner roles in a PeSIT session

During a session between two partners that are using the PeSIT protocol, the dialog is always asymmetrical, where the two partners have different but complementary roles. The session requester , the Initiator, takes the initiative regarding transfers, while the Responder (server partner) executes the requests received from the Initiator.

The Initiator sends files to the Responder (write), or the Responder sends files to the Initiator (read).

A given partner can have the following roles:

  • Initiator/Sender
  • Initiator/Receiver
  • Responder/Sender
  • Responder/Receiver

File transfer phases in a PeSIT session

The PeSIT protocol transfer phases include the following services, which occur in the order indicated in the File transfer phases in a PeSIT session diagram below.

Phase Description

Connect / Disconnect

Establish and release connection that is initiated either by the user or the protocol.

File select/ deselect

Create a file, select/deselect a file, and message transfer.

Open / Close

Open and close file services.


Read/write files, send data, set the synchronization points, transfer, resynchronize.


Restart a transfer, end-of-data transmission, end-of-transfer.

File transfer phases in a PeSIT session

Each phase is a step in the file transfer process, where the transfer cannot leave a phase without closing all the phases it contains.

About the connection

Password management

During the pre-connection and connection phases, passwords can be exchanged and validated by the two conversing partners.

There are two types of password that you define in the partner object:

  • Connection password sent by the Initiator
  • Connection acknowledgment password sent by the Responder

Establish a connection

Following a transfer request, the requesting Transfer CFT:

  • Opens a network session
  • Sends a protocol connection frame

At the server end, Transfer CFT always positively acknowledges the pre-connection message. Another Transfer CFT may perform an initial access control on the basis of the identifiers provided by the requester in the LOGON message.

If the pre-connection message is acknowledged positively, the requester then sends a protocol connection request.

On receiving the connection request, the server Transfer CFT checks that the remote partner is defined in the partner file. Transfer CFT then checks that the requester’s password corresponds to the remote partner's password.

If the protocol connection is rejected as a result of an incorrect identification, the requester receives a reject connection.

For more information concerning the interpretation of error messages or diagnostics from transfer incidents or problems, refer to Messages and error codes .

File and transfer attributes

The protocol negotiates the size of data blocks exchanged, as well as the compression type.

During the connection phase, the two partners negotiate the synchronization point frequency and the acknowledgment data window.

Related Links