Protocols/OSCAR/FLAP - Revision history

AD: Replaced content with "[https://gitlab.com/hollerith/cool/-/blob/main/docs/protocols/FLAP/README.md Moved]"

2026-01-17T18:58:48Z

Replaced content with "[https://gitlab.com/hollerith/cool/-/blob/main/docs/protocols/FLAP/README.md Moved]"

Show changes

AD at 10:34, 14 February 2021

2021-02-14T10:34:06Z

Show changes

AD at 21:25, 22 March 2020

2020-03-22T21:25:36Z

← Older revision		Revision as of 21:25, 22 March 2020
Line 135:		Line 135:
	\|}		\|}

	== ~~FLAP:~~ FLAP__FRAME_KEEP_ALIVE ==		== FLAP__FRAME_KEEP_ALIVE ==

	Many modern operating systems and networks come with firewalls and packet inspectors to protect the user. Unfortunately, these services and devices have proven to be buggy with long lived connections. We recommend that a client sends a FLAP KEEP_ALIVE packet to the server every minute after the connection has gone idle to help keep the connection alive. Please do not send it more often then once a minute or when the connection is not idle. There is no response to this message and a client will never receive a KEEP_ALIVE packet from the server.		Many modern operating systems and networks come with firewalls and packet inspectors to protect the user. Unfortunately, these services and devices have proven to be buggy with long lived connections. We recommend that a client sends a FLAP KEEP_ALIVE packet to the server every minute after the connection has gone idle to help keep the connection alive. Please do not send it more often then once a minute or when the connection is not idle. There is no response to this message and a client will never receive a KEEP_ALIVE packet from the server.

AD at 21:25, 22 March 2020

2020-03-22T21:25:21Z

← Older revision		Revision as of 21:25, 22 March 2020
Line 83:		Line 83:

	Example in hex: 2a011234000400000001		Example in hex: 2a011234000400000001

			== FLAP__FRAME_DATA ==

			A data frame will always just contain a single [[Protocols/OSCAR/SNAC\|SNAC]].

			{\| class="wikitable"
			! Name
			! Type
			! Notes
			\|-
			\| header
			\| [[Protocols/OSCAR/FLAP#FLAP_Header\|FLAP Header]]
			\| FLAP header, type will be FLAP__FRAME_KEEP_DATA
			\|-
			\| snacHeader
			\| [[Protocols/OSCAR/SNAC#Datatype:_SNAC_Header\|SNAC Header]]
			\| SNAC header
			\|-
			\| snac
			\| blob
			\| snac described by the SNAC header
			\|}

			== FLAP__FRAME_ERROR ==

			{\| class="wikitable"
			! Name
			! Type
			! Notes
			\|-
			\| header
			\| [[Protocols/OSCAR/FLAP#FLAP_Header\|FLAP Header]]
			\| FLAP header, type will be FLAP__FRAME_ERROR
			\|}

			== FLAP__FRAME_SIGNOFF ==

			This FLAP frame type is sent both to the client and server.

			* Sent to the client to tell it that it is getting bumped off gracefully. The client should NOT try to auto reconnect if it receives one of these messages.
			* Sent to the server by the client to tell it that it is going away gracefully.

			{\| class="wikitable"
			! Name
			! Type
			! Notes
			\|-
			\| header
			\| [[Protocols/OSCAR/FLAP#FLAP_Header\|FLAP Header]]
			\| FLAP header, type will be FLAP__FRAME_SIGNOFF
			\|}

			== FLAP: FLAP__FRAME_KEEP_ALIVE ==

			Many modern operating systems and networks come with firewalls and packet inspectors to protect the user. Unfortunately, these services and devices have proven to be buggy with long lived connections. We recommend that a client sends a FLAP KEEP_ALIVE packet to the server every minute after the connection has gone idle to help keep the connection alive. Please do not send it more often then once a minute or when the connection is not idle. There is no response to this message and a client will never receive a KEEP_ALIVE packet from the server.

			{\| class="wikitable"
			! Name
			! Type
			! Notes
			\|-
			\| header
			\| [[Protocols/OSCAR/FLAP#FLAP_Header\|FLAP Header]]
			\| FLAP header, type will be FLAP__FRAME_KEEP_ALIVE
			\|}

	[[Category:Stub]]		[[Category:Stub]]

AD at 21:16, 22 March 2020

2020-03-22T21:16:08Z

← Older revision		Revision as of 21:16, 22 March 2020
Line 61:		Line 61:
	\|}		\|}

	== ~~FLAP:~~ FLAP__FRAME_SIGNON ==		== FLAP__FRAME_SIGNON ==
	On connection, the server and client each send a FLAP SIGNON frame to initialize the connection. The sequence number field should be initialized with a random value. The data portion of the frame contains a 4 byte version number, currently always 1, followed by any TLVs that are required.		On connection, the server and client each send a FLAP SIGNON frame to initialize the connection. The sequence number field should be initialized with a random value. The data portion of the frame contains a 4 byte version number, currently always 1, followed by any TLVs that are required.

AD at 21:15, 22 March 2020

2020-03-22T21:15:49Z

← Older revision		Revision as of 21:15, 22 March 2020
Line 61:		Line 61:
	\|}		\|}

			== FLAP: FLAP__FRAME_SIGNON ==
	On connection, the server and client each send a FLAP SIGNON frame to initialize the connection. The sequence number field should be initialized with a random value. The data portion of the frame contains a 4 byte version number, currently always 1, followed by any TLVs that are required.		On connection, the server and client each send a FLAP SIGNON frame to initialize the connection. The sequence number field should be initialized with a random value. The data portion of the frame contains a 4 byte version number, currently always 1, followed by any TLVs that are required.

AD at 21:14, 22 March 2020

2020-03-22T21:14:59Z

← Older revision		Revision as of 21:14, 22 March 2020
Line 61:		Line 61:
	\|}		\|}

			On connection, the server and client each send a FLAP SIGNON frame to initialize the connection. The sequence number field should be initialized with a random value. The data portion of the frame contains a 4 byte version number, currently always 1, followed by any TLVs that are required.

			{\| class="wikitable"
			! Name
			! Type
			! Notes
			\|-
			\| header
			\| [[Protocols/OSCAR/FLAP#FLAP_Header\|FLAP Header]]
			\| FLAP header, type will be FLAP__FRAME_SIGNON
			\|-
			\| flapVersion
			\| uint32 (dword)
			\| Always 1
			\|-
			\| tlvs
			\| Array of [[Protocols/OSCAR/TLV\|TLV]] length payloadLength-4
			\| ''[Class: [[Protocols/OSCAR/Sign_On#TLV_Class:_FLAP_SIGNON_TAGS\|FLAP__SIGNON_TAGS]]]'' TLVs
			\|}

			Example in hex: 2a011234000400000001

	[[Category:Stub]]		[[Category:Stub]]

AD at 18:35, 22 March 2020

2020-03-22T18:35:14Z

@@ Line 1: / Line 1: @@
 {{Protocols/OSCAR}}
 FLAP (Frame Layer Protocol) provides the packet framing on top of TCP or TLS layer for the OSCAR protocol. Each message sent to and from the AIM backend is encapsulated in a FLAP frame that is easily identified using a 6 byte header followed by a variable length data segment. The payload of a FLAP frame is in most cases a [[Protocols/OSCAR/SNAC|SNAC]].
@@ Line 124: / Line 61: @@
 |}
 [[Category:Stub]]

AD at 22:35, 18 March 2020

2020-03-18T22:35:13Z

← Older revision		Revision as of 22:35, 18 March 2020
Line 1:		Line 1:
	{{Protocols/OSCAR}}		{{Protocols/OSCAR}}
			FLAP notes from another
			<!--
			Everything in the AIM protocol is embodied in AIM commands. The division is not of packets because more than one command may be sent in any one packet, depending on the transmit timing, etc. Commands are an abstraction above packets, and leads to the definition of the FLAP protocol below.

			Below is an attempt to generalize the layout of all AIM commands. The acronyms used are those used by the AIM client and the AIM divison of AOL as defined in the document at http://www.aim.aol.com/javadev/terminology.html. Please refer to that document if the explanations listed here are not complete enough for you.

			Fig 2.1 Generalized Command Structure

			FLAP
			+ Command Start (byte: 0x2a)
			+ Channel ID (byte)
			+ Sequence Number (word)
			+ Data Field Length (word)
			Data Field
			- Usually SNAC Data (variable)

			2.1 FLAP

			The FLAP is the protocol that sits at the bottom of everything communicated across AIM channels. This generally makes up the first 6 bytes of every AIM command. If this protocol is not obeyed, the OSCAR server will disconnect the offending client immediatly upon reception of a malformed command. This is not helpful for debuging, to say the least.

			2.1.1 FLAP: Headers

			Contained in the FLAP headers are: (in order of appearance)

			+ Command-Start [byte] (always 0x2a)
			+ Channel Identification [byte]
			+ Sequence Number [word]
			+ FLAP Data Field Length [word]

			This is followed immediatly by an unterminated FLAP Data Field, which concludes the FLAP command.

			2.1.2 FLAP: Data Field

			Normally, the FLAP Data Field contains a SNAC. The FLAP Data Field makes up the rest of the command (there is no FLAP-specific command terminator).

			2.1.3 Sequence Numbers

			Why AOL decided to use sequence numbering with TCP is beyond me. The retransmit and data integrity standards of TCP connections make this pointless. So, they're really just there for looks, though that doesn't mean that they can be incorrect. If the server gets an out-of-order command (according to the seqnums, not actual order), you will be disconnected.

			The sequence number origins are picked quite randomly. There is no connection between the sequence number set from the server and the set from the client. Sequence numbers are always incremented upward (towards 0xFFFF) for each command sent. If the seqence number does reach 0xFFFF, it will wrap to 0x0000, for obvious reasons. If you start a new connection, it is recommended that a new sequence number origin is picked for that connection, for purposes of internal coherency. Sequence numbers are independent of channels: there's a single series of sequence numbers per TCP connection (per socket). See section 2.1.4 for more information.

			2.1.4 Channels

			Channels are the method used to multiplex seperate paths of communication across the same TCP socket. These are analogous to TCP/UDP port numbers. Four channels are currently used by OSCAR:

			+ 0x01 - New Connection Negotiation
			+ 0x02 - SNAC data (non connection-oriented data)
			+ 0x03 - FLAP-level Error
			+ 0x04 - Close Connection Negotiation

			After a new connection (socket) is set up using channel 0x01, data should only be carried on channel 0x02, until a low-level FLAP error occurs (channel 0x03) or there is planned termination, which gets "negotiated" (on channel 0x04). Most live events processed during the lifespan of the client are done over channel 0x02. SNACs are never transmitted on any channel other than 0x02.

			2.1.5 Features of FLAP

			[Not yet.]

			2.1.6 Thoughts on FLAP Implementation

			The best way to read an incoming FLAP command is to first read only the starting 6 bytes (the FLAP headers). From these 6bytes, you can determine how many more bytes you need to read to complete the command, and how much memory you need to allocate to store it. Never read more or less than the number of bytes specified in the FLAP headers, or your read will result in a truncated or uninterpretable command. (If you read too much, you will probably end up reading the start of the next command, which is bad. Lost data is unacceptable in the AIM standard.)

			Because every command must follow FLAP guidelines, I'd recommend using a low-level routine to add the FLAP headers (normally, this will be the "flush transmit queue" routine, so that addition of sequence numbers and the rest of the FLAP headers is done as close timewise as possible to the command being put on the wire). This is the best way to prevent out-of-order seqnums from getting used (which, as stated earlier, is quite fatal).


			-->
	FLAP (Frame Layer Protocol) provides the packet framing on top of TCP or TLS layer for the OSCAR protocol. Each message sent to and from the AIM backend is encapsulated in a FLAP frame that is easily identified using a 6 byte header followed by a variable length data segment. The payload of a FLAP frame is in most cases a [[Protocols/OSCAR/SNAC\|SNAC]].		FLAP (Frame Layer Protocol) provides the packet framing on top of TCP or TLS layer for the OSCAR protocol. Each message sent to and from the AIM backend is encapsulated in a FLAP frame that is easily identified using a 6 byte header followed by a variable length data segment. The payload of a FLAP frame is in most cases a [[Protocols/OSCAR/SNAC\|SNAC]].

AD at 12:30, 17 March 2020

2020-03-17T12:30:14Z

@@ Line 1: / Line 1: @@
 {{Protocols/OSCAR}}
 FLAP (Frame Layer Protocol) provides the packet framing on top of TCP or TLS layer for the OSCAR protocol. Each message sent to and from the AIM backend is encapsulated in a FLAP frame that is easily identified using a 6 byte header followed by a variable length data segment. The payload of a FLAP frame is in most cases a [[Protocols/OSCAR/SNAC|SNAC]].
@@ Line 30: / Line 28: @@
 | uint16 (word)
 | Length of data, does not include the 6 byte header length
 |}