Schema "mule-tcp.xsd"
Target Namespace:
http://www.mulesoft.org/schema/mule/tcp
Defined Components:
15 global elements, 11 complexTypes, 1 attribute group
Default Namespace-Qualified Form:
Local Elements: qualified; Local Attributes: unqualified
Schema Location:
http://www.mulesoft.org/schema/mule/tcp/3.3/mule-tcp.xsd; see XML source
Imports Schemas (3):
mule-schemadoc.xsd [src], mule.xsd [src], xml.xsd [src]
Imported by Schemas (4):
_mule-all-included.xsd, mule-http.xsd [src], mule-ssl.xsd [src], mule-tls.xsd [src]
Annotation
The TCP transport enables events to be sent and received over TCP sockets.
All Element Summary
abstract-protocol
Type:
Content:
empty, 1 attribute
Subst.Gr:
may be substituted with 9 elements
Defined:
globally; see XML source
Used:
at 10 locations
connector Connects Mule to a TCP socket to send or receive data via the network.
Type:
Content:
complex, 16 attributes, attr. wildcard, 7 elements
Subst.Gr:
may substitute for element mule:abstract-connector
Defined:
globally; see XML source
Used:
never
custom-class-loading-protocol A length protocol that uses a specific class loader to load objects from streams
Type:
Content:
empty, 4 attributes
Subst.Gr:
may substitute for element abstract-protocol
Defined:
globally; see XML source
Used:
never
custom-protocol The custom-protocol element allows you to configure your own protocol implementation.
Type:
Content:
empty, 3 attributes
Subst.Gr:
may substitute for element abstract-protocol
Defined:
globally; see XML source
Used:
never
direct-protocol TCP does not guarantee that data written to a socket is transmitted in a single packet.
Type:
Content:
empty, 2 attributes
Subst.Gr:
may substitute for element abstract-protocol
Defined:
globally; see XML source
Used:
never
endpoint The endpoint element configures a global TCP endpoint definition.
Type:
Content:
complex, 13 attributes, attr. wildcard, 16 elements
Subst.Gr:
may substitute for element mule:abstract-global-endpoint
Defined:
globally; see XML source
Used:
never
eof-protocol TCP does not guarantee that data written to a socket is transmitted in a single packet, so if you want to transmit entire Mule messages reliably, you must specify an additional protocol.
Type:
Content:
empty, 2 attributes
Subst.Gr:
may substitute for element abstract-protocol
Defined:
globally; see XML source
Used:
never
inbound-endpoint The inbound-endpoint element configures the endpoint on which the messages are received.
Type:
Content:
complex, 13 attributes, attr. wildcard, 16 elements
Subst.Gr:
may substitute for element mule:abstract-inbound-endpoint
Defined:
globally; see XML source
Used:
never
length-protocol The length-protocol element configures the length protocol, which precedes each message with the number of bytes sent so that an entire message can be constructed on the received.
Type:
Content:
empty, 3 attributes
Subst.Gr:
may substitute for element abstract-protocol
Defined:
globally; see XML source
Used:
never
outbound-endpoint The outbound-endpoint element configures the endpoint where the messages are sent.
Type:
Content:
complex, 13 attributes, attr. wildcard, 16 elements
Subst.Gr:
may substitute for element mule:abstract-outbound-endpoint
Defined:
globally; see XML source
Used:
never
polling-connector Connects Mule to a TCP socket to send or receive data via the network.
Type:
Content:
complex, 18 attributes, attr. wildcard, 7 elements
Subst.Gr:
may substitute for element mule:abstract-connector
Defined:
globally; see XML source
Used:
never
safe-protocol Similar to length-protocol, safe-protocol also includes a prefix.
Type:
Content:
empty, 3 attributes
Subst.Gr:
may substitute for element abstract-protocol
Defined:
globally; see XML source
Used:
never
streaming-protocol TCP does not guarantee that data written to a socket is transmitted in a single packet, so if you want to transmit entire Mule messages reliably, you must specify an additional protocol.
Type:
Content:
empty, 1 attribute
Subst.Gr:
may substitute for element abstract-protocol
Defined:
globally; see XML source
Used:
never
xml-eof-protocol Similar to xml-protocol, the xml-eof-protocol element configures the XML protocol, but it will also use socket closure to terminate a message (even if the XML is not well-formed).
Type:
Content:
empty, 1 attribute
Subst.Gr:
may substitute for element abstract-protocol
Defined:
globally; see XML source
Used:
never
xml-protocol TCP does not guarantee that data written to a socket is transmitted in a single packet, so if you want to transmit entire Mule messages reliably, you must specify an additional protocol.
Type:
Content:
empty, 1 attribute
Subst.Gr:
may substitute for element abstract-protocol
Defined:
globally; see XML source
Used:
never
Complex Type Summary
Content:
empty, 1 attribute
Defined:
globally; see XML source
Includes:
definition of 1 attribute
Used:
Content:
empty, 2 attributes
Defined:
globally; see XML source
Includes:
definition of 1 attribute
Used:
Content:
empty, 4 attributes
Defined:
globally; see XML source
Includes:
definition of 1 attribute
Used:
Content:
empty, 3 attributes
Defined:
globally; see XML source
Includes:
definitions of 2 attributes
Used:
Content:
complex, 13 attributes, attr. wildcard, 16 elements
Defined:
globally; see XML source
Used:
Content:
complex, 13 attributes, attr. wildcard, 16 elements
Defined:
globally; see XML source
Used:
Content:
empty, 3 attributes
Defined:
globally; see XML source
Includes:
definition of 1 attribute
Used:
Content:
complex, 15 attributes, attr. wildcard, 6 elements
Defined:
globally; see XML source
Includes:
definitions of 11 attributes
Used:
Content:
complex, 13 attributes, attr. wildcard, 16 elements
Defined:
globally; see XML source
Used:
Content:
complex, 18 attributes, attr. wildcard, 7 elements
Defined:
globally; see XML source
Includes:
definitions of 2 attributes
Used:
Content:
complex, 16 attributes, attr. wildcard, 7 elements
Defined:
globally; see XML source
Includes:
definitions of 1 attribute, 1 element
Used:
Attribute Group Summary
Content:
Defined:
globally; see XML source
Includes:
definitions of 2 attributes
Used:
XML Source
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<xsd:schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://www.mulesoft.org/schema/mule/tcp" xmlns="http://www.mulesoft.org/schema/mule/tcp" xmlns:mule="http://www.mulesoft.org/schema/mule/core" xmlns:schemadoc="http://www.mulesoft.org/schema/mule/schemadoc" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:import namespace="http://www.w3.org/XML/1998/namespace"/>
<xsd:annotation>
<xsd:documentation>
The TCP transport enables events to be sent and received over TCP sockets.
</xsd:documentation>
<xsd:appinfo>
<schemadoc:short-name>TCP</schemadoc:short-name>
<schemadoc:page-title>TCP Transport</schemadoc:page-title>
<schemadoc:transport-features dispatchEvents="true" receiveEvents="true" requestEvents="true" streaming="true" transactions="false">
<schemadoc:MEPs default="request-response" supported="one-way, request-response"/>
</schemadoc:transport-features>
</xsd:appinfo>
</xsd:annotation>
<xsd:element name="connector" substitutionGroup="mule:abstract-connector" type="tcpConnectorType">
<xsd:annotation>
<xsd:documentation>
Connects Mule to a TCP socket to send or receive data via the network.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="polling-connector" substitutionGroup="mule:abstract-connector" type="pollingTcpConnectorType">
<xsd:annotation>
<xsd:documentation>
Connects Mule to a TCP socket to send or receive data via the network.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="pollingTcpConnectorType">
<xsd:complexContent>
<xsd:extension base="tcpConnectorType">
<xsd:attribute name="timeout" type="mule:substitutableLong">
<xsd:annotation>
<xsd:documentation>
The timeout to wait in milliseconds for data to come from the server
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="pollingFrequency" type="mule:substitutableLong">
<xsd:annotation>
<xsd:documentation>
The time in milliseconds to wait between each request to the TCP server.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="noProtocolTcpConnectorType">
<xsd:complexContent>
<xsd:extension base="mule:connectorType">
<xsd:attribute name="sendBufferSize" type="mule:substitutableInt">
<xsd:annotation>
<xsd:documentation>
The size of the buffer (in bytes) used when sending data, set on the socket itself.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="receiveBufferSize" type="mule:substitutableInt">
<xsd:annotation>
<xsd:documentation>
The size of the buffer (in bytes) used when receiving data, set on the socket itself.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="receiveBacklog" type="mule:substitutableInt">
<xsd:annotation>
<xsd:documentation>
The maximum queue length for incoming connections.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="sendTcpNoDelay" type="mule:substitutableBoolean">
<xsd:annotation>
<xsd:documentation>
If set, transmitted data is not collected together for greater efficiency but sent immediately.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="reuseAddress" type="mule:substitutableBoolean">
<xsd:annotation>
<xsd:documentation>
If set (the default), SO_REUSEADDRESS is set on server sockets before binding. This helps reduce "address already in use" errors when a socket is re-used.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="clientSoTimeout" type="mule:substitutableInt">
<xsd:annotation>
<xsd:documentation>
This sets the SO_TIMEOUT value when the socket is used as a client. Reading from the socket will block for up to this long (in milliseconds) before the read fails. A value of 0 (the default) causes the read to wait indefinitely (if no data arrives).
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="serverSoTimeout" type="mule:substitutableInt">
<xsd:annotation>
<xsd:documentation>
This sets the SO_TIMEOUT value when the socket is used as a server. Reading from the socket will block for up to this long (in milliseconds) before the read fails. A value of 0 (the default) causes the read to wait indefinitely (if no data arrives).
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="socketSoLinger" type="mule:substitutableInt">
<xsd:annotation>
<xsd:documentation>
This sets the SO_LINGER value. This is related to how long (in milliseconds) the socket will take to close so that any remaining data is transmitted correctly.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="keepSendSocketOpen" type="mule:substitutableBoolean">
<xsd:annotation>
<xsd:documentation>
If set, the socket is not closed after sending a message. This attribute only applies when sending data over a socket (Client).
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="keepAlive" type="mule:substitutableBoolean">
<xsd:annotation>
<xsd:documentation>
Enables SO_KEEPALIVE behavior on open sockets. This automatically checks socket connections that are open but unused for long periods and closes them if the connection becomes unavailable. This is a property on the socket itself and is used by a server socket to control whether connections to the server are kept alive before they are recycled.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="socketMaxWait" type="mule:substitutableInt">
<xsd:annotation>
<xsd:documentation>
Sets the maximum amount of time (in milliseconds) the socket pool should block waiting for a socket before throwing an exception. When less than or equal to 0 it may block indefinitely (the default).
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="tcpConnectorType">
<xsd:complexContent>
<xsd:extension base="noProtocolTcpConnectorType">
<xsd:sequence>
<xsd:element minOccurs="0" ref="abstract-protocol">
<xsd:annotation>
<xsd:documentation>
The class name for the protocol handler. This controls how the raw data stream is converted into messages. By default, messages are constructed as dara is received, with no correction for multiple packets or fragmentation. Typically, change this value, or use a transport that includes a protocol like HTTP.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="dispatcherFactory-ref" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Allows to define a custom message dispatcher factory
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="abstract-protocol" type="abstractProtocolType"/>
<xsd:complexType name="abstractProtocolType">
<xsd:annotation>
<xsd:documentation>
Rethrow the exception if read fails
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
<xsd:element name="streaming-protocol" substitutionGroup="abstract-protocol" type="abstractProtocolType">
<xsd:annotation>
<xsd:documentation>
TCP does not guarantee that data written to a socket is transmitted in a single packet, so if you want to transmit entire Mule messages reliably, you must specify an additional protocol. However, this is not an issue with streaming, so the streaming-protocol element is an alias for the "direct" (null) protocol.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="xml-protocol" substitutionGroup="abstract-protocol" type="abstractProtocolType">
<xsd:annotation>
<xsd:documentation>
TCP does not guarantee that data written to a socket is transmitted in a single packet, so if you want to transmit entire Mule messages reliably, you must specify an additional protocol. The xml-protocol element configures the XML protocol, which uses XML syntax to isolate messages from the stream of bytes received, so it will only work with well-formed XML.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="xml-eof-protocol" substitutionGroup="abstract-protocol" type="abstractProtocolType">
<xsd:annotation>
<xsd:documentation>
Similar to xml-protocol, the xml-eof-protocol element configures the XML protocol, but it will also use socket closure to terminate a message (even if the XML is not well-formed).
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="eof-protocol" substitutionGroup="abstract-protocol" type="byteOrMessageProtocolType">
<xsd:annotation>
<xsd:documentation>
TCP does not guarantee that data written to a socket is transmitted in a single packet, so if you want to transmit entire Mule messages reliably, you must specify an additional protocol. The eof-protocol element configures a protocol that simply accumulates all data until the socket closes and places it in a single message.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="direct-protocol" substitutionGroup="abstract-protocol" type="byteOrMessageProtocolType">
<xsd:annotation>
<xsd:documentation>
TCP does not guarantee that data written to a socket is transmitted in a single packet. Using the direct-protocol element to configure the "null" protocol does not change the normal TCP behavior, so message fragmentation may occur. For example, a single sent message may be received in several pieces, each as a separate received message. Typically, it is not a good choice for messaging within Mule, but it may be necessary to interface with external TCP-based protocols.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="byteOrMessageProtocolType">
<xsd:complexContent>
<xsd:extension base="abstractProtocolType">
<xsd:attribute name="payloadOnly" type="mule:substitutableBoolean" use="required">
<xsd:annotation>
<xsd:documentation>
Sends only the payload, not the entire Mule message object or its properties. This defaults to true when the protocol is not specified explicitly (when the safe protocol is used).
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="safe-protocol" substitutionGroup="abstract-protocol" type="lengthProtocolType">
<xsd:annotation>
<xsd:documentation>
Similar to length-protocol, safe-protocol also includes a prefix. Verification of the prefix allows mis-matched protocols to be detected and avoids interpreting "random" data as a message length (which may give out-of-memory errors). This is the default protocol in Mule 2.x.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:annotation>
<xsd:documentation>
A length protocol that uses a specific class loader to load objects from streams
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="customClassLoadingProtocolType">
<xsd:complexContent>
<xsd:extension base="lengthProtocolType">
<xsd:attribute name="classLoader-ref" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Allows Spring beans to be defined for class loading
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="length-protocol" substitutionGroup="abstract-protocol" type="lengthProtocolType">
<xsd:annotation>
<xsd:documentation>
The length-protocol element configures the length protocol, which precedes each message with the number of bytes sent so that an entire message can be constructed on the received.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="lengthProtocolType">
<xsd:complexContent>
<xsd:extension base="byteOrMessageProtocolType">
<xsd:attribute name="maxMessageLength" type="mule:substitutableInt">
<xsd:annotation>
<xsd:documentation>
An optional maximum length for the number of bytes in a single message. Messages larger than this will trigger an error in the receiver, but it give an assurance that no out-of-memory error will occur.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="custom-protocol" substitutionGroup="abstract-protocol" type="customProtocolType">
<xsd:annotation>
<xsd:documentation>
The custom-protocol element allows you to configure your own protocol implementation.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="customProtocolType">
<xsd:complexContent>
<xsd:extension base="abstractProtocolType">
<xsd:attribute name="class" type="mule:substitutableClass" use="optional">
<xsd:annotation>
<xsd:documentation>
A class that implements the TcpProtocol interface.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="ref" type="xsd:NMTOKEN" use="optional">
<xsd:annotation>
<xsd:documentation>
Reference to a spring bean that implements the TcpProtocol interface.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="inbound-endpoint" substitutionGroup="mule:abstract-inbound-endpoint" type="inboundEndpointType">
<xsd:annotation>
<xsd:documentation>
The inbound-endpoint element configures the endpoint on which the messages are received.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="inboundEndpointType">
<xsd:complexContent>
<xsd:extension base="mule:inboundEndpointType">
<xsd:attributeGroup ref="addressAttributes"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="outbound-endpoint" substitutionGroup="mule:abstract-outbound-endpoint" type="outboundEndpointType">
<xsd:annotation>
<xsd:documentation>
The outbound-endpoint element configures the endpoint where the messages are sent.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="outboundEndpointType">
<xsd:complexContent>
<xsd:extension base="mule:outboundEndpointType">
<xsd:attributeGroup ref="addressAttributes"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="endpoint" substitutionGroup="mule:abstract-global-endpoint" type="globalEndpointType">
<xsd:annotation>
<xsd:documentation>
The endpoint element configures a global TCP endpoint definition.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="globalEndpointType">
<xsd:complexContent>
<xsd:extension base="mule:globalEndpointType">
<xsd:attributeGroup ref="addressAttributes"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:attributeGroup name="addressAttributes">
<xsd:attribute name="host" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
The host of the TCP socket.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="port" type="mule:substitutablePortNumber">
<xsd:annotation>
<xsd:documentation>
The port of the TCP socket.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:attributeGroup>
</xsd:schema>

XML schema documentation generated with DocFlex/XML RE 1.8.5 using DocFlex/XML XSDDoc 2.5.0 template set. All content model diagrams generated by Altova XMLSpy via DocFlex/XML XMLSpy Integration.