diff --git a/VERSION.TXT b/VERSION.TXT index 783a16d..091958b 100644 --- a/VERSION.TXT +++ b/VERSION.TXT @@ -1,5 +1,20 @@ NORM Version History +Version 1.5r5 +============= + - Added NORM_REMOTE_SENDER_RESET event to notify app when the sender + has been reset due to instance id, etc change + - Fixed possibly critical issue in Protolib ProtoDispatcher where + threaded dispatcher use (as the NORM API uses) could possibly result + in timers not being serviced properly. Most likely the issue could + only occur under certain, heavier NORM API usage patterns. Nonetheless, + this is an important fix. (Thanks to Michael Savisko of Arris). + - Fixed FreeBSD build (Thanks to Hans Duedal) + - Changed from 'b' (build) numbering schema to 'r' (release) to reduce + confusion with respect to "beta" versus "stable" releases. + - Note there are some "in-progress" API extensions in this release that + are not yet described in the developer's guide documentation. + Version 1.5b4 ============= - Corrected change in behavior of non-blocking version of @@ -24,7 +39,7 @@ Version 1.5b2 notification check acking status). Acknowledged, graceful shutdown streams, are automatically closed. - Fixed issue with compilation for NormObjectSize constructor, MSB(), and LSB() - methods on 32-bit systems. Thanks to Bill Skiba. + methods on 32-bit systems. (Thanks to Bill Skiba). Version 1.5b1 ============= diff --git a/doc/NormDeveloperGuide.html b/doc/NormDeveloperGuide.html index 06058b7..dbe0d43 100644 --- a/doc/NormDeveloperGuide.html +++ b/doc/NormDeveloperGuide.html @@ -1,6 +1,6 @@ - NORM Developer's Guide (version 1.4b4)

NORM Developer's Guide (version 1.4b4)

Abstract

This document describes an application programming interface (API) for the Nack-Oriented Reliable Multicast (NORM) protocol implementation developed by the Protocol Engineering and Advance Networking (PROTEAN) Research Group of the United States Naval Research Laboratory (NRL). The NORM protocol provides general purpose reliable data transport for applications wishing to use Internet Protocol (IP) Multicast services for group data delivery. NORM can also support unicast (point-to-point) data communication and may be used for such when deemed appropriate. The current NORM protocol specification is given in the Internet Engineering Task Force (IETF) RFC 3940. This document is currently a reference guide to the NORM API of the NRL reference implementation. More tutorial material may be include in a future version of this document or a separate developer's tutorial may be created at a later date.

1. Background
2. Overview
2.1. API Initialization
2.2. Session Creation and Control
2.3. Data Transport
2.3.1. Data Transmission
2.3.2. Data Reception
2.4. API Event Notification
3. Build Notes
3.1. Unix Platforms
3.2. Win32/WiNCE Platforms
4. API Reference
4.1. API Variable Types and Constants
4.1.1. NormInstanceHandle
4.1.2. NormSessionHandle
4.1.3. NormSessionId
4.1.4. NormNodeHandle
4.1.5. NormNodeId
4.1.6. NormObjectHandle
4.1.7. NormObjectType
4.1.8. NormSize
4.1.9. NormObjectTransportId
4.1.10. NormEventType
4.1.11. NormEvent
4.1.12. NormDescriptor
4.1.13. NormFlushMode
4.1.14. NormProbingMode
4.1.15. NormSyncPolicy
4.1.16. NormNackingMode
4.1.17. NormRepairBoundary
4.1.18. NormAckingStatus
4.2. API Initialization and Operation
4.2.1. NormCreateInstance()
4.2.2. NormDestroyInstance()
4.2.3. NormStopInstance()
4.2.4. NormRestartInstance()
4.2.5. NormSetCacheDirectory()
4.2.6. NormGetNextEvent()
4.2.7. NormGetDescriptor()
4.3. Session Creation and Control Functions
4.3.1. NormCreateSession()
4.3.2. NormDestroySession()
4.3.3. NormSetUserData()
4.3.4. NormGetUserData()
4.3.5. NormGetLocalNodeId()
4.3.6. NormSetTxPort()
4.3.7. NormSetTxOnly()
4.3.8. NormSetRxPortReuse()
4.3.9. NormSetMulticastInterface()
4.3.10. NormSetTTL()
4.3.11. NormSetTOS()
4.3.12. NormSetLoopback()
4.3.13. NormSetFragmentation()
4.4. NORM Sender Functions
4.4.1. NormStartSender()
4.4.2. NormStopSender()
4.4.3. NormSetTxRate()
4.4.4. NormGetTxRate()
4.4.5. NormSetTxSocketBuffer()
4.4.6. NormSetFlowControl()
4.4.7. NormSetCongestionControl()
4.4.8. NormSetTxRateBounds()
4.4.9. NormSetTxCacheBounds()
4.4.10. NormSetAutoParity()
4.4.11. NormGetGrttEstimate()
4.4.12. NormSetGrttEstimate()
4.4.13. NormSetGrttMax()
4.4.14. NormSetGrttProbingMode()
4.4.15. NormSetGrttProbingInterval()
4.4.16. NormSetBackoffFactor()
4.4.17. NormSetGroupSize()
4.4.18. NormSetTxRobustFactor()
4.4.19. NormFileEnqueue()
4.4.20. NormDataEnqueue()
4.4.21. NormRequeueObject()
4.4.22. NormStreamOpen()
4.4.23. NormStreamClose()
4.4.24. NormStreamWrite()
4.4.25. NormStreamFlush()
4.4.26. NormStreamSetAutoFlush()
4.4.27. NormStreamSetPushEnable()
4.4.28. NormStreamHasVacancy()
4.4.29. NormStreamMarkEom()
4.4.30. NormSetWatermark()
4.4.31. NormCancelWatermark()
4.4.32. NormAddAckingNode()
4.4.33. NormRemoveAckingNode()
4.4.34. NormGetNextAckingNode()
4.4.35. NormGetAckingStatus()
4.4.36. NormSendCommand()
4.4.37. NormCancelCommand()
4.5. NORM Receiver Functions
4.5.1. NormStartReceiver()
4.5.2. NormStopReceiver()
4.5.3. NormSetRxCacheLimit()
4.5.4. NormSetRxSocketBuffer()
4.5.5. NormSetSilentReceiver()
4.5.6. NormSetDefaultUnicastNack()
4.5.7. NormNodeSetUnicastNack()
4.5.8. NormSetDefaultSyncPolicy()
4.5.9. NormSetDefaultNackingMode()
4.5.10. NormNodeSetNackingMode()
4.5.11. NormObjectSetNackingMode()
4.5.12. NormSetDefaultRepairBoundary()
4.5.13. NormNodeSetRepairBoundary()
4.5.14. NormSetDefaultRxRobustFactor()
4.5.15. NormNodeSetRxRobustFactor()
4.5.16. NormStreamRead()
4.5.17. NormStreamSeekMsgStart()
4.5.18. NormStreamGetReadOffset()
4.6. NORM Object Functions
4.6.1. NormObjectGetType()
4.6.2. NormObjectHasInfo()
4.6.3. NormObjectGetInfoLength()
4.6.4. NormObjectGetInfo()
4.6.5. NormObjectGetSize()
4.6.6. NormObjectGetBytesPending()
4.6.7. NormObjectCancel()
4.6.8. NormObjectRetain()
4.6.9. NormObjectRelease()
4.6.10. NormFileGetName()
4.6.11. NormFileRename()
4.6.12. NormDataAccessData()
4.6.13. NormDataDetachData()
4.6.14. NormObjectGetSender()
4.7. NORM Node Functions
4.7.1. NormNodeGetId()
4.7.2. NormNodeGetAddress()
4.7.3. NormNodeGetGrtt()
4.7.4. NormNodeGetCommand()
4.7.5. NormNodeFreeBuffers()
4.7.6. NormNodeDelete()
4.7.7. NormNodeRetain()
4.7.8. NormNodeRelease()
4.8. NORM Debugging Functions
4.8.1. NormSetDebugLevel()
4.8.2. NormOpenDebugLog()
4.8.3. NormCloseDebugLog()
4.8.4. NormOpenDebugPipe()
4.8.5. NormCloseDebugPipe()

1. Background

This document describes an application programming interface (API) for the Nack-Oriented Reliable Multicast (NORM) protocol implementation developed by the Protocol Engineering and Advance Networking (PROTEAN) Research Group of the United States Naval Research Laboratory (NRL). The NORM protocol provides general purpose reliable data transport for applications wishing to use Internet Protocol (IP) Multicast services for group data delivery. NORM can also support unicast (point-to-point) data communication and may be used for such when deemed appropriate. The current NORM protocol specification is given in the Internet Engineering Task Force (IETF) RFC 5740.

The NORM protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgement (NACK) mechanism for transport reliability and offers additional protocol mechanisms to conduct reliable multicast sessions with limited "a priori" coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) from the senders to receivers. The protocol offers a number of features to allow different types of applications or possibly other higher-level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based repair and other proven reliable multicast transport techniques in its design.

The NRL NORM library attempts to provide a general useful capability for development of reliable multicast applications for bulk file or other data delivery as well as support of stream-based transport with possible real-time delivery requirements. The API allows access to many NORM protocol parameters and control functions to tailor performance for specific applications. While default parameters, where provided, can be useful to a potential wide range of requirements, the many different possible group communication paradigms dictate different needs for different applications. Even with NORM, the developer should have a thorough understanding of the specific application's group communication needs.

2. Overview

The NORM API has been designed to provide simple, straightforward access to and control of NORM protocol state and functions. Functions are provided to create and initialize instances of the NORM API and associated transport sessions (NormSessions). Subsequently, NORM data transmission (NormSender) operation can be activated and the application can queue various types of data (NormObjects) for reliable transport. Additionally or alternatively, NORM reception (NormReceiver) operation can also be enabled on a per-session basis and the protocol implementation alerts the application of receive events.

By default, the NORM API will create an operating system thread in which the NORM protocol engine runs. This allows user application code and the underlying NORM code to execute somewhat independently of one another. The NORM protocol thread notifies the application of various protocol events through a thread-safe event dispatching mechanism and API calls are provided to allow the application to control NORM operation. (Note: API mechanisms for lower-level, non-threaded control and execution of the NORM protocol engine code may also be provided in the future.)

The NORM API operation can be roughly summarized with the following categories of functions:

  1. API Initialization

  2. Session Creation and Control

  3. Data Transport

  4. API Event Notification

Note the order of these categories roughly reflects the order of function calls required to use NORM in an application. The first step is to create and initialize, as needed, at least one instance of the NORM API. Then one or more NORM transport sessions (where a "session" corresponds to data exchanges on a given multicast group (or unicast address) and host port number) may be created and controlled. Applications may participate as senders and/or receivers within a NORM session. NORM senders transmit data to the session destination address (usually an IP multicast group) while receivers are notified of incoming data. The NORM API provides and event notification scheme to notify the application of significant sender and receiver events. There are also a number support functions provided for the application to control and monitor its participation within a NORM transport session.

2.1. API Initialization

The NORM API requires that an application explicitly create at least one instance of the NORM protocol engine that is subsequently used as a conduit for further NORM API calls. By default, the NORM protocol engine runs in its own operating system thread and interacts with the application in a thread-safe manner through the API calls and event dispatching mechanism.

In general, only a single thread should access the NormGetNextEvent() API call for a given NormInstance. This function serves as the conduit for delivering NORM protocol engine events to the application. A NORM application can be designed to be single-threaded, even with multiple active NormSessions, but also multiple API instances can be created (see NormCreateInstance()) as needed for applications with specific requirements for accessing and controlling participation in multiple NormSessions from separate operating system multiple threads. Or, alternatively, a single NormInstance could be used, with a "master thread" serving as an intermediary between the NormGetNextEvent() function, demultiplexing and dispatching events as appropriate to other "child threads" that are created to handle "per-NormSession" input/output. The advantage of this alternative approach is that the end result would be one NORM protocol engine thread plus one "master thread" plus one "child thread" per NormSession instead of two threads (protocol engine plus application thread) per NormSession if such multi-threaded operation is needed by the application.

2.2. Session Creation and Control

Once an API instance has been successfully created, the application may then create NORM transport session instances as needed. The application can participate in each session as a sender and/or receiver of data. If an application is participating as a sender, it may enqueue data transport objects for transmission. The control of transmission is largely left to the senders and API calls are provided to control transmission rate, FEC parameters, etc. Applications participating as receivers will be notified via the NORM API's event dispatching mechanism of pending and completed reliable reception of data along with other significant events. Additionally, API controls for some optional NORM protocol mechanisms, such as positive acknowledgment collection, are also provided.

Note when multiple senders are involved, receivers allocate system resources (buffer space) for each active sender. With a very large number of concurrently active senders, this may translate to significant memory allocation on receiver nodes. Currently, the API allows the application to control how much buffer space is allocated for each active sender (NOTE: In the future, API functions may be provided limit the number of active senders monitored and/or provide the application with finer control over receive buffer allocation, perhaps on a per sender basis).

2.3. Data Transport

The NORM protocol supports transport of three basic types of data content. These include the types NORM_OBJECT_FILE and NORM_OBJECT_DATA which represent predetermined, fixed-size application data content. The only differentiation with respect to these two types is the implicit "hint" to the receiver to use non-volatile (i.e. file system) storage or memory. This "hint" lets the receiver allocate appropriate storage space with no other information on the incoming data. The NORM implementation reads/writes data for the NORM_OBJECT_FILE type directly from/to file storage, while application memory space is accessed for the NORM_OBJECT_DATA type. The third data content type, NORM_OBJECT_STREAM, represents unbounded, possibly persistent, streams of data content. Using this transport paradigm, traditional, byte-oriented streaming transport service (e.g. similar to that provided by a TCP socket) can be provided. Additionally, NORM has provisions for application-defined message-oriented transport where receivers can recover message boundaries without any "handshake" with the sender. Stream content is buffered by the NORM implementation for transmission/retransmission and as it is received.

2.3.1. Data Transmission

The behavior of data transport operation is largely placed in the control of the NORM sender(s). NORM senders controls their data transmission rate, forward error correction (FEC) encoding settings, and parameters controlling feedback from the receiver group. Multiple senders may operate in a session, each with independent transmission parameters. NORM receivers learn needed parameter values from fields in NORM message headers.

NORM transport "objects" (file, data, or stream) are queued for transmission by NORM senders. NORM senders may also cancel transmission of objects at any time. The NORM sender controls the transmission rate either manually (fixed transmission rate) or automatically when NORM congestion control operation is enabled. The NORM congestion control mechanism is designed to be "friendly" to other data flows on the network, fairly sharing available bandwidth.NormSetAutoParity()) to achieve reliable transfer) receive object transmission before any extensive repair process that may be required to satisfy other receivers with poor network connectivity. The repair boundary can also be set for individual remote senders using the NormNodeSetRepairBoundary() function.NORM_OBJECT_FILE objects. This function must be called before any file objects may be received and thus should be called before any calls to NormStartReceiver() are made. However, note that the cache directory may be changed even during active NORM reception. In this case, the new specified directory path will be used for subsequently-received files. Any files received before a directory path change will remain in the previous cache location. Note that the NormFileRename() function may be used to rename, and thus potentially move, received files after reception has begun.

By default, the NORM sender transmits application-enqueued data content, providing repair transmissions (usually in the form of FEC messages) only when requested by NACKs from the receivers. However, the application may also configure NORM to proactively send some amount of FEC content along with the original data content to create a "robust" transmission that, in some cases, may be reliably received without any NACKing activity. This can allow for some degree of reliable protocol operation even without receiver feedback available. NORM senders may also requeue (within the limits of "transmit cache" settings) objects for repeat transmission, and receivers may combine together multiple transmissions to reliably receive content. Additionally, hybrid proactive/reactive FEC repair operation is possible with the receiver NACK process as a "backup" for when network packet loss exceeds the repair capability of the proactive FEC settings.

The NRL NORM implementation also supports optional collection of positive acknowledgment from a subset of the receiver group at application-determined positions during data transmission. The NORM API allows the application to specify the receiver subset ("acking node list") and set "watermark" points for which positive acknowledgement is collected. This process can provide the application with explicit flow control for an application-determined critical set of receivers in the group.

For a NORM application to perform data transmission, it must first create a session using NormCreateSession() and make a call to NormStartSender() before sending actual user data. The functions NormFileEnqueue(), NormDataEnqueue(), and NormStreamWrite() are available for the application to pass data to the NORM protocol engine for transmission. Note that to use NormStreamWrite(), a "sender stream" must first be created using NormStreamOpen(). In the case of NormFileEnqueue() and NormDataEnqueue(), the NORM protocol engine directly accesses the application file or memory space to refer to the transmitted content and does not make its own copy of this data.

The calls to enqueue transport objects or write to a stream may be called at any time, but the NORM_TX_QUEUE_EMPTY and NORM_TX_QUEUE_VACANCY notification events (see NormGetNextEvent()) provide useful cues for when these functions may be successfully called. Typically, an application might catch both NORM_TX_QUEUE_EMPTY and NORM_TX_QUEUE_VACANCY event types as cues for enqueuing additional transport objects or writing to a stream. However, an application may choose to cue off of NORM_TX_QUEUE_EMPTY only if it wishes to provide the "freshest" data to NORM for transmission. The advantage of additionally using NORM_TX_QUEUE_VACANCY is that if the application uses this cue to fill up NORM transport object or stream buffers, it can keep the NORM stream busy sending data and realize the highest possible transmission rate when attempting very high speed communication (Otherwise, the NORM protocol engine may experience some "dead air time" waiting for the application thread to respond to a NORM_TX_QUEUE_EMPTY event). Note the sender application can control buffer depths as needed with the NormSetTxCacheBounds() and NormStreamOpen() calls. Additionally, it is possible for applications to configure the transmit object "cache" (see NormSetTxCacheBounds()) and use the NormRequeueObject() call (for objects that have not yet received a NORM_TX_OBJECT_PURGED notification) to effect a sort of "data carousel" operation with repeated transmission of the cached objects. The NORM_TX_OBJECT_SENT notification can be used a cue to properly control the "requeue" cycle(s).

The NORM implementation provides a form of timer-based flow control that limits how quickly sender applications may enqueue new objects or stream data for transmission. The NormSetFlowControl() call is provided to control this behavior, including the option to disable it. This timer-based mechanism is a type of "soft" flow control by allowing receivers "sufficient" time to request repair of pending data the sender has enqueued. A more explicit form of flow control using the optional "watermark flushing" mechanism is described below.

Another cue that can be leveraged by the sender application to determine when it is appropriate to enqueue (or write) additional data for transmission is the NORM_TX_WATERMARK_COMPLETED event. This event is posted when the flushing or explicit positive acknowledgment collection process has completed for a "watermark" point in transmission that was set by the sender (see NormSetWatermark() and NormAddAckingNode()). A list of NormNodeId values can be supplied from which explicit acknowledgement is expected and/or the NormNodeId NORM_NODE_NONE can be set (using NormAddAckingNode()) for completion of a NACK-based version of the watermark flushing procedure. This flushing process can be used as a flow control mechanism for NORM applications. Note this is distinct from NORM's congestion control mechanism that, while it provides network-friendly transmission rate control, does guarantee flow control to receiving nodes.NORM_NODE_NONE can be set (using NormAddAckingNode()) for completion of a NACK-based version of the watermark flushing procedure. This flushing process can be used as a flow control mechanism for NORM applications. Note this is distinct from NORM's congestion control mechanism that, while it provides network-friendly transmission rate control, does guarantee flow control to receiving nodes.

2.3.2. Data Reception

NORM receiver applications learn of active senders and their corresponding pending and completed data transfers, etc via the API event dispatching mechanism. By default, NORM receivers use NACK messages to request repair of transmitted content from the originating sender as needed to achieve reliable transfer. Some API functions are available to provide some additional control over the NACKing behavior, such as initially NACKing for NORM_INFO content only or even to the extent of disabling receiver feedback (silent receiver or emission-controlled (EMCON) operation) entirely. Otherwise, the parameters and operation of reliable data transmission are left to sender applications and receivers learn of sender parameters in NORM protocol message headers and are instructed by NORM_CMD messages from the sender(s).

With respect to the NORM API, the receiver application is informed of new senders and receive data objects via the the NORM_REMOTE_SENDER_NEW and NORM_RX_OBJECT_NEW notifications, respectfully. Additionally, object reception progress is indicated with the NORM_RX_OBJECT_UPDATED notification and this also serves as an indicator for the NORM_OBJECT_STREAM type that the receive application should make calls to NormStreamRead() to read newly received stream content. NORM sender status is also conveyed via the NORM_REMOTE_SENDER_ACTIVE and NORM_REMOTE_SENDER_INACTIVE notifications. For example, the receiver application may use the NORM_REMOTE_SENDER_INACTIVE as a cue to make calls to NormNodeFreeBuffers() and/or NormNodeDelete() to free memory resources allocated for buffering received content for the given sender. The amount of memory allocated per sender is set in the NormStartReceiver() call.

2.4. API Event Notification

An asynchronous event dispatching mechanism is provided to notify the application of significant NORM protocol events. The centerpiece of this is the NormGetNextEvent() function that can be used to retrieve the next NORM protocol engine event in the form of a NormEvent structure. This function will typically block until a NormEvent occurs. However, non-blocking operation may be achieved by using the NormGetDescriptor() call to get a NormDescriptor (file descriptor) value (Unix int or Win32 HANDLE) suitable for use in a asynchronous I/O monitoring functions such as the Unix select() or Win32 MsgWaitForMultipleObjects() system calls. The a NormDescriptor will be signaled when a NormEvent is available. For Win32 platforms, dispatching of a user-defined Windows message for NORM event notification is also planned for a future update to the NORM API.

3. Build Notes

To build applications that use the NORM library, a path to the "normApi.h" header file must be provided and the linker step needs to reference the NORM library file ("libnorm.a" for Unix platforms and "Norm.lib" for Win32 platforms). NORM also depends upon the NRL Protean Protocol Prototyping toolkit "Protokit" library (a.k.a "Protolib") (static library files "libProtokit.a" for Unix and "Protokit.lib" for Win32). Shared or dynamically-linked versions of these libraries may also be built from the NORM source code or provided. Depending upon the platform, some additional library dependencies may be required to support the needs of NORM and/or Protokit. These are described below.

The "makefiles" directory contains Unix Makefiles for various platforms the "win32" and "wince" sub-directories there contain Microsoft Visual C++ (VC++) and Embedded VC++ project files for building the NORM implementation. Additionally, a "waf" (Python-based build tool) build option is supported that can be used to build and install the NORM library code on the supported platforms. Finally, Python and Java bindings to the NORM API are included and "src/python" and "src/java" directories contain the code for these and the "makefiles/java" directory contains Makefiles to build the NORM Java JNI bindings. Note the "waf" tool can also be used to build the Java and Python bindings.

3.1. Unix Platforms

NORM has been built and tested on Linux (various architectures), MacOS (BSD), Solaris, and IRIX (SGI) platforms. The code should be readily portable to other Unix platforms.

To support IPv6 operation, the NORM and the Protokit library must be compiled with the "HAVE_IPV6" macro defined. This is default in the NORM and Protokit Makefiles for platforms that support IPv6. It is important that NORM and Protokit be built with this macro defined the same. With NORM, it is recommended that "large file support" options be enabled when possible.

The NORM API uses threading so that the NORM protocol engine may run independent of the application. Thus the "POSIX Threads" library must be included ("-pthread") in the linking step. MacOS/BSD also requires the addition of the "-lresolv" (resolver) library and Solaris requires the dynamic loader, network/socket, and resolver libraries ("-lnsl -lsocket -lresolv") to achieve successful compilation. The Makefiles in the NORM source code distribution are a reference for these requirements. Note that MacOS 9 and earlier are not supported.

Additionally, it is critical that the _FILE_OFFSET_BITS macro be consistently defined for the NORM library build and the application build using the library. The distributed NORM Makefiles have -D_FILE_OFFSET_BITS=64 set in the compilation to enable "large file support". Applications built using NORM should have the same compilation option set to operate correctly (The definition of the NormSize type in "normApi.h" depends upon this compilation flag).

3.2. Win32/WiNCE Platforms

NORM has been built using Microsoft's Visual C++ (6.0 and .NET) and Embedded VC++ 4.2 environments. In addition to proper macro definitions (e.g., HAVE_IPV6, etc) that are included in the respective "Protokit" and "NORM" project files, it is important that common code generation settings be used when building the NORM application. The NORM and Protokit projects are built with the "Multi-threading DLL" library usage set. The NORM API requires multi-threading support. This is a critical setting and numerous compiler and linker errors will result if this is not properly set for your application project.

NORM and Protokit also depend on the Winsock 2.0 ("ws2_32.lib" (or "ws2.lib" (WinCE)) and the IP Helper API ("iphlpapi.lib") libraries and these must be included in the project "Link" attributes.

An additional note is that a bug in VC++ 6.0 and earlier compilers (includes embedded VC++ 4.x compilers) prevent compilation of Protokit-based code with debugging capabilities enabled. However, this has been resolved in VC++ .NET and is hoped to be resolved in the future for the WinCE build tools.

Operation on Windows NT4 (and perhaps other older Windows operating systems) requires that the compile time macro WINVER=0x0400 defined. This is because the version of the IP Helper API library (iphlpapi.lib) used by Protolib (and hence NORM) for this system doesn't support some of the functions defined for this library. This may be related to IPv6 support issues so it may be possible that the Protolib build could be tweaked to provide a single binary executable suitable for IPv4 operation only across a large range of Windows platforms.

4. API Reference

This section provides a reference to the NORM API variable types, constants and functions.

4.1. API Variable Types and Constants

The NORM API defines and enumerates a number of supporting variable types and values which are used in different function calls. The variable types are described here.

4.1.1. NormInstanceHandle

The NormInstanceHandle type is returned when a NORM API instance is created (see NormCreateInstance()). This handle can be subsequently used for API calls which require reference to a specific NORM API instance. By default, each NORM API instance instantiated creates an operating system thread for protocol operation. Note that multiple NORM transport sessions may be created for a single API instance. In general, it is expected that applications will create a single NORM API instance, but some multi-threaded application designs may prefer multiple corresponding NORM API instances. The value NORM_INSTANCE_INVALID corresponds to an invalid API instance.

4.1.2. NormSessionHandle

The NormSessionHandle type is used to reference NORM transport sessions which have been created using the NormCreateSession() API call. Multiple NormSessionHandle values may be associated with a given NormInstanceHandle. The special value NORM_SESSION_INVALID is used to refer to invalid session references.

4.1.3. NormSessionId

The NormSessionId type is used by applications to uniquely identify their instance of participation as a sender within a NormSession. This type is a parameter to the NormStartSender() function. Robust applications can use different NormSessionId values when initiating sender operation so that receivers can discriminate when a sender has terminated and restarted (whether intentional or due to system failure). For example, an application could cache its prior NormSessionId value in non-volatile storage which could then be recovered and incremented (for example) upon system restart to produce a new value. The NormSessionId value is used for the value of the instance_id field in NORM protocol sender messages (see the NORM protocol specification) and receivers use this field to detect sender restart within a NormSession.

4.1.4. NormNodeHandle

The NormNodeHandle type is used to reference state kept by the NORM implementation with respect to other participants within a NormSession. Most typically, the NormNodeHandle is used by receiver applications to dereference information about remote senders of data as needed. The special value NORM_NODE_INVALID corresponds to an invalid reference.

4.1.5. NormNodeId

The NormNodeId type corresponds to a 32-bit numeric value which should uniquely identify a participant (node) in a given NormSession. The NormNodeGetId() function can be used to retrieve this value given a valid NormNodeHandle. The special value NORM_NODE_NONE corresponds to an invalid (or null) node while the value NORM_NODE_ANY serves as a wild card value for some functions.

4.1.6. NormObjectHandle

The NormObjectHandle type is used to reference state kept for data transport objects being actively transmitted or received. The state kept for NORM transport objects is temporary, but the NORM API provides a function to persistently retain state associated with a sender or receiver NormObjectHandle (see NormObjectRetain()) if needed. For sender objects, unless explicitly retained, the NormObjectHandle can be considered valid until the referenced object is explicitly canceled (see NormObjectCancel()) or purged from the sender transmission queue (see the event NORM_TX_OBJECT_PURGED). For receiver objects, these handles should be treated as valid only until a subsequent call to NormGetNextEvent() unless, again, specifically retained. The special value NORM_OBJECT_INVALID corresponds to an invalid transport object reference.

4.1.7. NormObjectType

The NormObjectType type is an enumeration of possible NORM data transport object types. As previously mentioned, valid types include:

  1. NORM_OBJECT_FILE

  2. NORM_OBJECT_DATA, and

  3. NORM_OBJECT_STREAM

Given a NormObjectHandle, the application may determine an object's type using the NormObjectGetType() function call. A special NormObjectType value, NORM_OBJECT_NONE, indicates an invalid object type.

4.1.8. NormSize

The NormSize is the type used for NormObject size information. For example, the NormObjectGetSize() function returns a value of type NormSize. The range of NormSize values depends upon the operating system and NORM library compilation settings. With "large file support" enabled, as is the case with distributed NORM library "Makefiles", the NormSize type is a 64-bit integer. However, some platforms may support only 32-bit object sizes.

4.1.9. NormObjectTransportId

The NormObjectTransportId type is a 16-bit numerical value assigned to NormObjects by senders during active transport. These values are temporarily unique with respect to a given sender within a NormSession and may be "recycled" for use for future transport objects. NORM sender nodes assign these values in a monotonically increasing fashion during the course of a session as part of protocol operation. Typically, the application should not need access to these values, but an API call such as NormObjectGetTransportId() (TBD) may be provided to retrieve these values if needed. (Note this type may be deprecated; i.e., it may not be needed at since the NormRequeueObject() function is implemented using handles only, but _some_ applications requiring persistence even after a system reboot may need the ability to recall previous transport ids?)

4.1.10. NormEventType

The NormEventType is an enumeration of NORM API events. "Events" are used by the NORM API to signal the application of significant NORM protocol operation events (e.g., receipt of a new receive object, etc). A description of possible NormEventType values and their interpretation is given below. The function call NormGetNextEvent() is used to retrieve events from the NORM protocol engine.

4.1.11. NormEvent

The NormEvent type is a structure used to describe significant NORM protocol events. This structure is defined as follows:

typedef struct
+   NORM Developer's Guide (version 1.5b5)
 NORM Developer's Guide (version 1.5b5)
Abstract
This document describes an application programming interface (API) for the Nack-Oriented Reliable Multicast (NORM) protocol implementation developed by the Protocol Engineering and Advance Networking (PROTEAN) Research Group of the United States Naval Research Laboratory (NRL). The NORM protocol provides general purpose reliable data transport for applications wishing to use Internet Protocol (IP) Multicast services for group data delivery. NORM can also support unicast (point-to-point) data communication and may be used for such when deemed appropriate. The current NORM protocol specification is given in the Internet Engineering Task Force (IETF) RFC 3940. This document is currently a reference guide to the NORM API of the NRL reference implementation. More tutorial material may be include in a future version of this document or a separate developer's tutorial may be created at a later date.
Table of Contents
1. Background
2. Overview
2.1. API Initialization
2.2. Session Creation and Control
2.3. Data Transport
2.3.1. Data Transmission
2.3.2. Data Reception
2.4. API Event Notification
3. Build Notes
3.1. Unix Platforms
3.2. Win32/WiNCE Platforms
4. API Reference
4.1. API Variable Types and Constants
4.1.1. NormInstanceHandle
4.1.2. NormSessionHandle
4.1.3. NormSessionId
4.1.4. NormNodeHandle
4.1.5. NormNodeId
4.1.6. NormObjectHandle
4.1.7. NormObjectType
4.1.8. NormSize
4.1.9. NormObjectTransportId
4.1.10. NormEventType
4.1.11. NormEvent
4.1.12. NormDescriptor
4.1.13. NormFlushMode
4.1.14. NormProbingMode
4.1.15. NormSyncPolicy
4.1.16. NormNackingMode
4.1.17. NormRepairBoundary
4.1.18. NormAckingStatus
4.2. API Initialization and Operation
4.2.1. NormCreateInstance()
4.2.2. NormDestroyInstance()
4.2.3. NormStopInstance()
4.2.4. NormRestartInstance()
4.2.5. NormSetCacheDirectory()
4.2.6. NormGetNextEvent()
4.2.7. NormGetDescriptor()
4.3. Session Creation and Control Functions
4.3.1. NormCreateSession()
4.3.2. NormDestroySession()
4.3.3. NormSetUserData()
4.3.4. NormGetUserData()
4.3.5. NormGetLocalNodeId()
4.3.6. NormSetTxPort()
4.3.7. NormSetTxOnly()
4.3.8. NormSetRxPortReuse()
4.3.9. NormSetMulticastInterface()
4.3.10. NormSetSSM()
4.3.11. NormSetTTL()
4.3.12. NormSetTOS()
4.3.13. NormSetLoopback()
4.3.14. NormSetFragmentation()
4.4. NORM Sender Functions
4.4.1. NormStartSender()
4.4.2. NormStopSender()
4.4.3. NormSetTxRate()
4.4.4. NormGetTxRate()
4.4.5. NormSetTxSocketBuffer()
4.4.6. NormSetFlowControl()
4.4.7. NormSetCongestionControl()
4.4.8. NormSetTxRateBounds()
4.4.9. NormSetTxCacheBounds()
4.4.10. NormSetAutoParity()
4.4.11. NormGetGrttEstimate()
4.4.12. NormSetGrttEstimate()
4.4.13. NormSetGrttMax()
4.4.14. NormSetGrttProbingMode()
4.4.15. NormSetGrttProbingInterval()
4.4.16. NormSetBackoffFactor()
4.4.17. NormSetGroupSize()
4.4.18. NormSetTxRobustFactor()
4.4.19. NormFileEnqueue()
4.4.20. NormDataEnqueue()
4.4.21. NormRequeueObject()
4.4.22. NormStreamOpen()
4.4.23. NormStreamClose()
4.4.24. NormStreamWrite()
4.4.25. NormStreamFlush()
4.4.26. NormStreamSetAutoFlush()
4.4.27. NormStreamSetPushEnable()
4.4.28. NormStreamHasVacancy()
4.4.29. NormStreamMarkEom()
4.4.30. NormSetWatermark()
4.4.31. NormCancelWatermark()
4.4.32. NormAddAckingNode()
4.4.33. NormRemoveAckingNode()
4.4.34. NormGetNextAckingNode()
4.4.35. NormGetAckingStatus()
4.4.36. NormSendCommand()
4.4.37. NormCancelCommand()
4.5. NORM Receiver Functions
4.5.1. NormStartReceiver()
4.5.2. NormStopReceiver()
4.5.3. NormSetRxCacheLimit()
4.5.4. NormSetRxSocketBuffer()
4.5.5. NormSetSilentReceiver()
4.5.6. NormSetDefaultUnicastNack()
4.5.7. NormNodeSetUnicastNack()
4.5.8. NormSetDefaultSyncPolicy()
4.5.9. NormSetDefaultNackingMode()
4.5.10. NormNodeSetNackingMode()
4.5.11. NormObjectSetNackingMode()
4.5.12. NormSetDefaultRepairBoundary()
4.5.13. NormNodeSetRepairBoundary()
4.5.14. NormSetDefaultRxRobustFactor()
4.5.15. NormNodeSetRxRobustFactor()
4.5.16. NormStreamRead()
4.5.17. NormStreamSeekMsgStart()
4.5.18. NormStreamGetReadOffset()
4.6. NORM Object Functions
4.6.1. NormObjectGetType()
4.6.2. NormObjectHasInfo()
4.6.3. NormObjectGetInfoLength()
4.6.4. NormObjectGetInfo()
4.6.5. NormObjectGetSize()
4.6.6. NormObjectGetBytesPending()
4.6.7. NormObjectCancel()
4.6.8. NormObjectRetain()
4.6.9. NormObjectRelease()
4.6.10. NormFileGetName()
4.6.11. NormFileRename()
4.6.12. NormDataAccessData()
4.6.13. NormDataDetachData()
4.6.14. NormObjectGetSender()
4.7. NORM Node Functions
4.7.1. NormNodeGetId()
4.7.2. NormNodeGetAddress()
4.7.3. NormNodeGetGrtt()
4.7.4. NormNodeGetCommand()
4.7.5. NormNodeFreeBuffers()
4.7.6. NormNodeDelete()
4.7.7. NormNodeRetain()
4.7.8. NormNodeRelease()
4.8. NORM Debugging Functions
4.8.1. NormSetDebugLevel()
4.8.2. NormOpenDebugLog()
4.8.3. NormCloseDebugLog()
4.8.4. NormOpenDebugPipe()
4.8.5. NormCloseDebugPipe()
1. Background
This document describes an application programming interface (API) for the Nack-Oriented Reliable Multicast (NORM) protocol implementation developed by the Protocol Engineering and Advance Networking (PROTEAN) Research Group of the United States Naval Research Laboratory (NRL). The NORM protocol provides general purpose reliable data transport for applications wishing to use Internet Protocol (IP) Multicast services for group data delivery. NORM can also support unicast (point-to-point) data communication and may be used for such when deemed appropriate. The current NORM protocol specification is given in the Internet Engineering Task Force (IETF) RFC 5740.
The NORM protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgement (NACK) mechanism for transport reliability and offers additional protocol mechanisms to conduct reliable multicast sessions with limited "a priori" coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) from the senders to receivers. The protocol offers a number of features to allow different types of applications or possibly other higher-level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based repair and other proven reliable multicast transport techniques in its design.
The NRL NORM library attempts to provide a general useful capability for development of reliable multicast applications for bulk file or other data delivery as well as support of stream-based transport with possible real-time delivery requirements. The API allows access to many NORM protocol parameters and control functions to tailor performance for specific applications. While default parameters, where provided, can be useful to a potential wide range of requirements, the many different possible group communication paradigms dictate different needs for different applications. Even with NORM, the developer should have a thorough understanding of the specific application's group communication needs.
2. Overview
The NORM API has been designed to provide simple, straightforward access to and control of NORM protocol state and functions. Functions are provided to create and initialize instances of the NORM API and associated transport sessions (NormSessions). Subsequently, NORM data transmission (NormSender) operation can be activated and the application can queue various types of data (NormObjects) for reliable transport. Additionally or alternatively, NORM reception (NormReceiver) operation can also be enabled on a per-session basis and the protocol implementation alerts the application of receive events.
By default, the NORM API will create an operating system thread in which the NORM protocol engine runs. This allows user application code and the underlying NORM code to execute somewhat independently of one another. The NORM protocol thread notifies the application of various protocol events through a thread-safe event dispatching mechanism and API calls are provided to allow the application to control NORM operation. (Note: API mechanisms for lower-level, non-threaded control and execution of the NORM protocol engine code may also be provided in the future.)
The NORM API operation can be roughly summarized with the following categories of functions:
  1. API Initialization
  2. Session Creation and Control
  3. Data Transport
  4. API Event Notification
Note the order of these categories roughly reflects the order of function calls required to use NORM in an application. The first step is to create and initialize, as needed, at least one instance of the NORM API. Then one or more NORM transport sessions (where a "session" corresponds to data exchanges on a given multicast group (or unicast address) and host port number) may be created and controlled. Applications may participate as senders and/or receivers within a NORM session. NORM senders transmit data to the session destination address (usually an IP multicast group) while receivers are notified of incoming data. The NORM API provides and event notification scheme to notify the application of significant sender and receiver events. There are also a number support functions provided for the application to control and monitor its participation within a NORM transport session.
2.1. API Initialization
The NORM API requires that an application explicitly create at least one instance of the NORM protocol engine that is subsequently used as a conduit for further NORM API calls. By default, the NORM protocol engine runs in its own operating system thread and interacts with the application in a thread-safe manner through the API calls and event dispatching mechanism.
In general, only a single thread should access the NormGetNextEvent() API call for a given NormInstance. This function serves as the conduit for delivering NORM protocol engine events to the application. A NORM application can be designed to be single-threaded, even with multiple active NormSessions, but also multiple API instances can be created (see NormCreateInstance()) as needed for applications with specific requirements for accessing and controlling participation in multiple NormSessions from separate operating system multiple threads. Or, alternatively, a single NormInstance could be used, with a "master thread" serving as an intermediary between the NormGetNextEvent() function, demultiplexing and dispatching events as appropriate to other "child threads" that are created to handle "per-NormSession" input/output. The advantage of this alternative approach is that the end result would be one NORM protocol engine thread plus one "master thread" plus one "child thread" per NormSession instead of two threads (protocol engine plus application thread) per NormSession if such multi-threaded operation is needed by the application.
2.2. Session Creation and Control
Once an API instance has been successfully created, the application may then create NORM transport session instances as needed. The application can participate in each session as a sender and/or receiver of data. If an application is participating as a sender, it may enqueue data transport objects for transmission. The control of transmission is largely left to the senders and API calls are provided to control transmission rate, FEC parameters, etc. Applications participating as receivers will be notified via the NORM API's event dispatching mechanism of pending and completed reliable reception of data along with other significant events. Additionally, API controls for some optional NORM protocol mechanisms, such as positive acknowledgment collection, are also provided.
Note when multiple senders are involved, receivers allocate system resources (buffer space) for each active sender. With a very large number of concurrently active senders, this may translate to significant memory allocation on receiver nodes. Currently, the API allows the application to control how much buffer space is allocated for each active sender (NOTE: In the future, API functions may be provided limit the number of active senders monitored and/or provide the application with finer control over receive buffer allocation, perhaps on a per sender basis).
2.3. Data Transport
The NORM protocol supports transport of three basic types of data content. These include the types NORM_OBJECT_FILE and NORM_OBJECT_DATA which represent predetermined, fixed-size application data content. The only differentiation with respect to these two types is the implicit "hint" to the receiver to use non-volatile (i.e. file system) storage or memory. This "hint" lets the receiver allocate appropriate storage space with no other information on the incoming data. The NORM implementation reads/writes data for the NORM_OBJECT_FILE type directly from/to file storage, while application memory space is accessed for the NORM_OBJECT_DATA type. The third data content type, NORM_OBJECT_STREAM, represents unbounded, possibly persistent, streams of data content. Using this transport paradigm, traditional, byte-oriented streaming transport service (e.g. similar to that provided by a TCP socket) can be provided. Additionally, NORM has provisions for application-defined message-oriented transport where receivers can recover message boundaries without any "handshake" with the sender. Stream content is buffered by the NORM implementation for transmission/retransmission and as it is received.
2.3.1. Data Transmission
The behavior of data transport operation is largely placed in the control of the NORM sender(s). NORM senders controls their data transmission rate, forward error correction (FEC) encoding settings, and parameters controlling feedback from the receiver group. Multiple senders may operate in a session, each with independent transmission parameters. NORM receivers learn needed parameter values from fields in NORM message headers.
NORM transport "objects" (file, data, or stream) are queued for transmission by NORM senders. NORM senders may also cancel transmission of objects at any time. The NORM sender controls the transmission rate either manually (fixed transmission rate) or automatically when NORM congestion control operation is enabled. The NORM congestion control mechanism is designed to be "friendly" to other data flows on the network, fairly sharing available bandwidth.NormSetAutoParity()) to achieve reliable transfer) receive object transmission before any extensive repair process that may be required to satisfy other receivers with poor network connectivity. The repair boundary can also be set for individual remote senders using the NormNodeSetRepairBoundary() function.NORM_OBJECT_FILE objects. This function must be called before any file objects may be received and thus should be called before any calls to NormStartReceiver() are made. However, note that the cache directory may be changed even during active NORM reception. In this case, the new specified directory path will be used for subsequently-received files. Any files received before a directory path change will remain in the previous cache location. Note that the NormFileRename() function may be used to rename, and thus potentially move, received files after reception has begun.
By default, the NORM sender transmits application-enqueued data content, providing repair transmissions (usually in the form of FEC messages) only when requested by NACKs from the receivers. However, the application may also configure NORM to proactively send some amount of FEC content along with the original data content to create a "robust" transmission that, in some cases, may be reliably received without any NACKing activity. This can allow for some degree of reliable protocol operation even without receiver feedback available. NORM senders may also requeue (within the limits of "transmit cache" settings) objects for repeat transmission, and receivers may combine together multiple transmissions to reliably receive content. Additionally, hybrid proactive/reactive FEC repair operation is possible with the receiver NACK process as a "backup" for when network packet loss exceeds the repair capability of the proactive FEC settings.
The NRL NORM implementation also supports optional collection of positive acknowledgment from a subset of the receiver group at application-determined positions during data transmission. The NORM API allows the application to specify the receiver subset ("acking node list") and set "watermark" points for which positive acknowledgement is collected. This process can provide the application with explicit flow control for an application-determined critical set of receivers in the group.
For a NORM application to perform data transmission, it must first create a session using NormCreateSession() and make a call to NormStartSender() before sending actual user data. The functions NormFileEnqueue(), NormDataEnqueue(), and NormStreamWrite() are available for the application to pass data to the NORM protocol engine for transmission. Note that to use NormStreamWrite(), a "sender stream" must first be created using NormStreamOpen(). In the case of NormFileEnqueue() and NormDataEnqueue(), the NORM protocol engine directly accesses the application file or memory space to refer to the transmitted content and does not make its own copy of this data.
The calls to enqueue transport objects or write to a stream may be called at any time, but the NORM_TX_QUEUE_EMPTY and NORM_TX_QUEUE_VACANCY notification events (see NormGetNextEvent()) provide useful cues for when these functions may be successfully called. Typically, an application might catch both NORM_TX_QUEUE_EMPTY and NORM_TX_QUEUE_VACANCY event types as cues for enqueuing additional transport objects or writing to a stream. However, an application may choose to cue off of NORM_TX_QUEUE_EMPTY only if it wishes to provide the "freshest" data to NORM for transmission. The advantage of additionally using NORM_TX_QUEUE_VACANCY is that if the application uses this cue to fill up NORM transport object or stream buffers, it can keep the NORM stream busy sending data and realize the highest possible transmission rate when attempting very high speed communication (Otherwise, the NORM protocol engine may experience some "dead air time" waiting for the application thread to respond to a NORM_TX_QUEUE_EMPTY event). Note the sender application can control buffer depths as needed with the NormSetTxCacheBounds() and NormStreamOpen() calls. Additionally, it is possible for applications to configure the transmit object "cache" (see NormSetTxCacheBounds()) and use the NormRequeueObject() call (for objects that have not yet received a NORM_TX_OBJECT_PURGED notification) to effect a sort of "data carousel" operation with repeated transmission of the cached objects. The NORM_TX_OBJECT_SENT notification can be used a cue to properly control the "requeue" cycle(s).
The NORM implementation provides a form of timer-based flow control that limits how quickly sender applications may enqueue new objects or stream data for transmission. The NormSetFlowControl() call is provided to control this behavior, including the option to disable it. This timer-based mechanism is a type of "soft" flow control by allowing receivers "sufficient" time to request repair of pending data the sender has enqueued. A more explicit form of flow control using the optional "watermark flushing" mechanism is described below.
Another cue that can be leveraged by the sender application to determine when it is appropriate to enqueue (or write) additional data for transmission is the NORM_TX_WATERMARK_COMPLETED event. This event is posted when the flushing or explicit positive acknowledgment collection process has completed for a "watermark" point in transmission that was set by the sender (see NormSetWatermark() and NormAddAckingNode()). A list of NormNodeId values can be supplied from which explicit acknowledgement is expected and/or the NormNodeId NORM_NODE_NONE can be set (using NormAddAckingNode()) for completion of a NACK-based version of the watermark flushing procedure. This flushing process can be used as a flow control mechanism for NORM applications. Note this is distinct from NORM's congestion control mechanism that, while it provides network-friendly transmission rate control, does guarantee flow control to receiving nodes.NORM_NODE_NONE can be set (using NormAddAckingNode()) for completion of a NACK-based version of the watermark flushing procedure. This flushing process can be used as a flow control mechanism for NORM applications. Note this is distinct from NORM's congestion control mechanism that, while it provides network-friendly transmission rate control, does guarantee flow control to receiving nodes.
2.3.2. Data Reception
NORM receiver applications learn of active senders and their corresponding pending and completed data transfers, etc via the API event dispatching mechanism. By default, NORM receivers use NACK messages to request repair of transmitted content from the originating sender as needed to achieve reliable transfer. Some API functions are available to provide some additional control over the NACKing behavior, such as initially NACKing for NORM_INFO content only or even to the extent of disabling receiver feedback (silent receiver or emission-controlled (EMCON) operation) entirely. Otherwise, the parameters and operation of reliable data transmission are left to sender applications and receivers learn of sender parameters in NORM protocol message headers and are instructed by NORM_CMD messages from the sender(s).
With respect to the NORM API, the receiver application is informed of new senders and receive data objects via the the NORM_REMOTE_SENDER_NEW and NORM_RX_OBJECT_NEW notifications, respectfully. Additionally, object reception progress is indicated with the NORM_RX_OBJECT_UPDATED notification and this also serves as an indicator for the NORM_OBJECT_STREAM type that the receive application should make calls to NormStreamRead() to read newly received stream content. NORM sender status is also conveyed via the NORM_REMOTE_SENDER_ACTIVE and NORM_REMOTE_SENDER_INACTIVE notifications. For example, the receiver application may use the NORM_REMOTE_SENDER_INACTIVE as a cue to make calls to NormNodeFreeBuffers() and/or NormNodeDelete() to free memory resources allocated for buffering received content for the given sender. The amount of memory allocated per sender is set in the NormStartReceiver() call.
2.4. API Event Notification
An asynchronous event dispatching mechanism is provided to notify the application of significant NORM protocol events. The centerpiece of this is the NormGetNextEvent() function that can be used to retrieve the next NORM protocol engine event in the form of a NormEvent structure. This function will typically block until a NormEvent occurs. However, non-blocking operation may be achieved by using the NormGetDescriptor() call to get a NormDescriptor (file descriptor) value (Unix int or Win32 HANDLE) suitable for use in a asynchronous I/O monitoring functions such as the Unix select() or Win32 MsgWaitForMultipleObjects() system calls. The a NormDescriptor will be signaled when a NormEvent is available. For Win32 platforms, dispatching of a user-defined Windows message for NORM event notification is also planned for a future update to the NORM API.
3. Build Notes
To build applications that use the NORM library, a path to the "normApi.h" header file must be provided and the linker step needs to reference the NORM library file ("libnorm.a" for Unix platforms and "Norm.lib" for Win32 platforms). NORM also depends upon the NRL Protean Protocol Prototyping toolkit "Protokit" library (a.k.a "Protolib") (static library files "libProtokit.a" for Unix and "Protokit.lib" for Win32). Shared or dynamically-linked versions of these libraries may also be built from the NORM source code or provided. Depending upon the platform, some additional library dependencies may be required to support the needs of NORM and/or Protokit. These are described below.
The "makefiles" directory contains Unix Makefiles for various platforms the "win32" and "wince" sub-directories there contain Microsoft Visual C++ (VC++) and Embedded VC++ project files for building the NORM implementation. Additionally, a "waf" (Python-based build tool) build option is supported that can be used to build and install the NORM library code on the supported platforms. Finally, Python and Java bindings to the NORM API are included and "src/python" and "src/java" directories contain the code for these and the "makefiles/java" directory contains Makefiles to build the NORM Java JNI bindings. Note the "waf" tool can also be used to build the Java and Python bindings.
3.1. Unix Platforms
NORM has been built and tested on Linux (various architectures), MacOS (BSD), Solaris, and IRIX (SGI) platforms. The code should be readily portable to other Unix platforms.
To support IPv6 operation, the NORM and the Protokit library must be compiled with the "HAVE_IPV6" macro defined. This is default in the NORM and Protokit Makefiles for platforms that support IPv6. It is important that NORM and Protokit be built with this macro defined the same. With NORM, it is recommended that "large file support" options be enabled when possible.
The NORM API uses threading so that the NORM protocol engine may run independent of the application. Thus the "POSIX Threads" library must be included ("-pthread") in the linking step. MacOS/BSD also requires the addition of the "-lresolv" (resolver) library and Solaris requires the dynamic loader, network/socket, and resolver libraries ("-lnsl -lsocket -lresolv") to achieve successful compilation. The Makefiles in the NORM source code distribution are a reference for these requirements. Note that MacOS 9 and earlier are not supported.
Additionally, it is critical that the _FILE_OFFSET_BITS macro be consistently defined for the NORM library build and the application build using the library. The distributed NORM Makefiles have -D_FILE_OFFSET_BITS=64 set in the compilation to enable "large file support". Applications built using NORM should have the same compilation option set to operate correctly (The definition of the NormSize type in "normApi.h" depends upon this compilation flag).
3.2. Win32/WiNCE Platforms
NORM has been built using Microsoft's Visual C++ (6.0 and .NET) and Embedded VC++ 4.2 environments. In addition to proper macro definitions (e.g., HAVE_IPV6, etc) that are included in the respective "Protokit" and "NORM" project files, it is important that common code generation settings be used when building the NORM application. The NORM and Protokit projects are built with the "Multi-threading DLL" library usage set. The NORM API requires multi-threading support. This is a critical setting and numerous compiler and linker errors will result if this is not properly set for your application project.
NORM and Protokit also depend on the Winsock 2.0 ("ws2_32.lib" (or "ws2.lib" (WinCE)) and the IP Helper API ("iphlpapi.lib") libraries and these must be included in the project "Link" attributes.
An additional note is that a bug in VC++ 6.0 and earlier compilers (includes embedded VC++ 4.x compilers) prevent compilation of Protokit-based code with debugging capabilities enabled. However, this has been resolved in VC++ .NET and is hoped to be resolved in the future for the WinCE build tools.
Operation on Windows NT4 (and perhaps other older Windows operating systems) requires that the compile time macro WINVER=0x0400 defined. This is because the version of the IP Helper API library (iphlpapi.lib) used by Protolib (and hence NORM) for this system doesn't support some of the functions defined for this library. This may be related to IPv6 support issues so it may be possible that the Protolib build could be tweaked to provide a single binary executable suitable for IPv4 operation only across a large range of Windows platforms.
4. API Reference
This section provides a reference to the NORM API variable types, constants and functions.
4.1. API Variable Types and Constants
The NORM API defines and enumerates a number of supporting variable types and values which are used in different function calls. The variable types are described here.
4.1.1. NormInstanceHandle
The NormInstanceHandle type is returned when a NORM API instance is created (see NormCreateInstance()). This handle can be subsequently used for API calls which require reference to a specific NORM API instance. By default, each NORM API instance instantiated creates an operating system thread for protocol operation. Note that multiple NORM transport sessions may be created for a single API instance. In general, it is expected that applications will create a single NORM API instance, but some multi-threaded application designs may prefer multiple corresponding NORM API instances. The value NORM_INSTANCE_INVALID corresponds to an invalid API instance.
4.1.2. NormSessionHandle
The NormSessionHandle type is used to reference NORM transport sessions which have been created using the NormCreateSession() API call. Multiple NormSessionHandle values may be associated with a given NormInstanceHandle. The special value NORM_SESSION_INVALID is used to refer to invalid session references.
4.1.3. NormSessionId
The NormSessionId type is used by applications to uniquely identify their instance of participation as a sender within a NormSession. This type is a parameter to the NormStartSender() function. Robust applications can use different NormSessionId values when initiating sender operation so that receivers can discriminate when a sender has terminated and restarted (whether intentional or due to system failure). For example, an application could cache its prior NormSessionId value in non-volatile storage which could then be recovered and incremented (for example) upon system restart to produce a new value. The NormSessionId value is used for the value of the instance_id field in NORM protocol sender messages (see the NORM protocol specification) and receivers use this field to detect sender restart within a NormSession.
4.1.4. NormNodeHandle
The NormNodeHandle type is used to reference state kept by the NORM implementation with respect to other participants within a NormSession. Most typically, the NormNodeHandle is used by receiver applications to dereference information about remote senders of data as needed. The special value NORM_NODE_INVALID corresponds to an invalid reference.
4.1.5. NormNodeId
The NormNodeId type corresponds to a 32-bit numeric value which should uniquely identify a participant (node) in a given NormSession. The NormNodeGetId() function can be used to retrieve this value given a valid NormNodeHandle. The special value NORM_NODE_NONE corresponds to an invalid (or null) node while the value NORM_NODE_ANY serves as a wild card value for some functions.
4.1.6. NormObjectHandle
The NormObjectHandle type is used to reference state kept for data transport objects being actively transmitted or received. The state kept for NORM transport objects is temporary, but the NORM API provides a function to persistently retain state associated with a sender or receiver NormObjectHandle (see NormObjectRetain()) if needed. For sender objects, unless explicitly retained, the NormObjectHandle can be considered valid until the referenced object is explicitly canceled (see NormObjectCancel()) or purged from the sender transmission queue (see the event NORM_TX_OBJECT_PURGED). For receiver objects, these handles should be treated as valid only until a subsequent call to NormGetNextEvent() unless, again, specifically retained. The special value NORM_OBJECT_INVALID corresponds to an invalid transport object reference.
4.1.7. NormObjectType
The NormObjectType type is an enumeration of possible NORM data transport object types. As previously mentioned, valid types include:
  1. NORM_OBJECT_FILE
  2. NORM_OBJECT_DATA, and
  3. NORM_OBJECT_STREAM
Given a NormObjectHandle, the application may determine an object's type using the NormObjectGetType() function call. A special NormObjectType value, NORM_OBJECT_NONE, indicates an invalid object type.
4.1.8. NormSize
The NormSize is the type used for NormObject size information. For example, the NormObjectGetSize() function returns a value of type NormSize. The range of NormSize values depends upon the operating system and NORM library compilation settings. With "large file support" enabled, as is the case with distributed NORM library "Makefiles", the NormSize type is a 64-bit integer. However, some platforms may support only 32-bit object sizes.
4.1.9. NormObjectTransportId
The NormObjectTransportId type is a 16-bit numerical value assigned to NormObjects by senders during active transport. These values are temporarily unique with respect to a given sender within a NormSession and may be "recycled" for use for future transport objects. NORM sender nodes assign these values in a monotonically increasing fashion during the course of a session as part of protocol operation. Typically, the application should not need access to these values, but an API call such as NormObjectGetTransportId() (TBD) may be provided to retrieve these values if needed. (Note this type may be deprecated; i.e., it may not be needed at since the NormRequeueObject() function is implemented using handles only, but _some_ applications requiring persistence even after a system reboot may need the ability to recall previous transport ids?)
4.1.10. NormEventType
The NormEventType is an enumeration of NORM API events. "Events" are used by the NORM API to signal the application of significant NORM protocol operation events (e.g., receipt of a new receive object, etc). A description of possible NormEventType values and their interpretation is given below. The function call NormGetNextEvent() is used to retrieve events from the NORM protocol engine.
4.1.11. NormEvent
The NormEvent type is a structure used to describe significant NORM protocol events. This structure is defined as follows:
typedef struct
 {
     NormEventType     type;
     NormSessionHandle session; 
@@ -64,7 +64,7 @@ void NormGetUserData(NormSessionHandle sessionHandle);
4.3.4.2. Description
This function retrieves the "user data" value set for the specified sessionHandle with a prior call to NormSetUserData().
4.3.4.3. Return Values
This function returns the user data value set for the specified session. If no user data value has been previously set, a NULL (i.e., (const void*)0) value is returned.
4.3.5. NormGetLocalNodeId()
4.3.5.1. Synopsis
#include <normApi.h>
 
-NormNodeId NormGetLocalNodeId(NormSessionHandle sessionHandle);
4.3.5.2. Description
This function retrieves the NormNodeId value used for the application's participation in the NormSession identified by the sessionHandle parameter. The value may have been explicitly set during the NormCreateSession() call or may have been automatically derived using the host computer's "default" IP network address.
4.3.5.3. Return Values
The returned value indicates the NormNode identifier used by the NORM protocol engine for the local application's participation in the specified NormSession.
4.3.6. NormSetTxPort()
4.3.6.1. Synopsis
#include <normApi.h>
+NormNodeId NormGetLocalNodeId(NormSessionHandle sessionHandle);
4.3.5.2. Description
This function retrieves the NormNodeId value used for the application's participation in the NormSession identified by the sessionHandle parameter. The value may have been explicitly set during the NormCreateSession() call or may have been automatically derived using the host computer's "default" IP network address.
4.3.5.3. Return Valuess
The returned value indicates the NormNode identifier used by the NORM protocol engine for the local application's participation in the specified NormSession.
4.3.6. NormSetTxPort()
4.3.6.1. Synopsis
#include <normApi.h>
 
 bool NormSetTxPort(NormSessionHandle sessionHandle,
                    unsigned short    txPort,
@@ -84,264 +84,267 @@ void NormSetMulticastInterface(NormSessionHandle session,
                                const char*       interfaceName);
4.3.9.2. Description
This function specifies which host network interface is used for IP Multicast transmissions and group membership. This should be called before any call to NormStartSender() or NormStartReceiver() is made so that the IP multicast group is joined on the proper host interface. However, if a call to NormSetMulticastInterface() is made after either of these function calls, the call will not affect the group membership interface, but only dictate that a possibly different network interface is used for transmitted NORM messages. Thus, the code:
NormSetMulticastInterface(session, "interface1");
 NormStartReceiver(session, ...);
-NormSetMulticastInterface(session, "interface2");
will result in NORM group membership (i.e. multicast reception) being managed on "interface1" while NORM multicast transmissions are made via "interface2".
4.3.9.3. Return Values
A return value of true indicates success while a return value of false indicates that the specified interface was valid. This function will always return true if made before calls to NormStartSender() or NormStartReceiver(). However, those calls may fail if an invalid interface was specified with the call described here.
4.3.10. NormSetTTL()
4.3.10.1. Synopsis
#include <normApi.h>
+NormSetMulticastInterface(session, "interface2");
will result in NORM group membership (i.e. multicast reception) being managed on "interface1" while NORM multicast transmissions are made via "interface2".
4.3.9.3. Return Values
A return value of true indicates success while a return value of false indicates that the specified interface was invalid. This function will always return true if made before calls to NormStartSender() or NormStartReceiver(). However, those calls may fail if an invalid interface was specified with the call described here.
4.3.10. NormSetSSM()
4.3.10.1. Synopsis
#include <normApi.h>
 
-bool NormSetTTL(NormSessionHandle session,
-                unsigned char     ttl);
4.3.10.2. Description
This function specifies the time-to-live (ttl) for IP Multicast datagrams generated by NORM for the specified sessionHandle. The IP TTL field limits the number of router "hops" that a generated multicast packet may traverse before being dropped. For example, if TTL is equal to one, the transmissions will be limited to the local area network (LAN) of the host computers network interface. Larger TTL values should be specified to span large networks. Also note that some multicast router configurations use artificial "TTL threshold" values to constrain some multicast traffic to an administrative boundary. In these cases, the NORM TTL setting must also exceed the router "TTL threshold" in order for the NORM traffic to be allowed to exit the administrative area.
4.3.10.3. Return Values
A return value of true indicates success while a return value of false indicates that the specified ttl could not be set. This function will always return true if made before calls to NormStartSender() or NormStartReceiver(). However, those calls may fail if the desired ttl value cannot be set.
4.3.11. NormSetTOS()
4.3.11.1. Synopsis
#include <normApi.h>
+bool NormSetSSM(NormSessionHandle session,
+                const char*       sourceAddress);
4.3.10.2. Description
This function sets the source address for Source-Specific Multicast (SSM) operation.  This should be called before any call to NormStartSender() or NormStartReceiver() is made so that the proper group join is done.  The receiver application MUST also use the NormSetDefaultUnicastNack() call so that feedback traffic is directed back to appropriate sender.
4.3.10.3. Return Values
A return value of true indicates success while a return value of false indicates that the specified source address was invalid. Note that if a valid IP address is specified but is improper for SSM (e.g., an IP multicast address) the later calls to  NormStartSender() or NormStartReceiver() may fail.
4.3.11. NormSetTTL()
4.3.11.1. Synopsis
#include <normApi.h>
 
-bool NormSetTOS(NormSessionHandle       sessionHandle,
-                unsigned char           tos);
4.3.11.2. Description
This function specifies the type-of-service (tos) field value used in IP Multicast datagrams generated by NORM for the specified sessionHandle. The IP TOS field value can be used as an indicator that a "flow" of packets may merit special Quality-of-Service (QoS) treatment by network devices. Users should refer to applicable QoS information for their network to determine the expected interpretation and treatment (if any) of packets with explicit TOS marking.
4.3.11.3. Return Values
A return value of true indicates success while a return value of false indicates that the specified tos could not be set. This function will always return true if made before calls to NormStartSender() or NormStartReceiver(). However, those calls may fail if the desired tos value cannot be set.
4.3.12. NormSetLoopback()
4.3.12.1. Synopsis
#include <normApi.h>
+bool NormSetTTL(NormSessionHandle session,
+                unsigned char     ttl);
4.3.11.2. Description
This function specifies the time-to-live (ttl) for IP Multicast datagrams generated by NORM for the specified sessionHandle. The IP TTL field limits the number of router "hops" that a generated multicast packet may traverse before being dropped. For example, if TTL is equal to one, the transmissions will be limited to the local area network (LAN) of the host computers network interface. Larger TTL values should be specified to span large networks. Also note that some multicast router configurations use artificial "TTL threshold" values to constrain some multicast traffic to an administrative boundary. In these cases, the NORM TTL setting must also exceed the router "TTL threshold" in order for the NORM traffic to be allowed to exit the administrative area.
4.3.11.3. Return Values
A return value of true indicates success while a return value of false indicates that the specified ttl could not be set. This function will always return true if made before calls to NormStartSender() or NormStartReceiver(). However, those calls may fail if the desired ttl value cannot be set.
4.3.12. NormSetTOS()
4.3.12.1. Synopsis
#include <normApi.h>
 
-void NormSetLoopback(NormSessionHandle sessionHandle,
-                     bool              loopbackEnable);
4.3.12.2. Description
This function enables or disables loopback operation for the indicated NORM sessionHandle. If loopbackEnable is set to true, loopback operation is enabled which allows the application to receive its own message traffic. Thus, an application which is both actively receiving and sending may receive its own transmissions. Note it is expected that this option would be principally be used for test purposes and that applications would generally not need to transfer data to themselves. If loopbackEnable is false, the application is prevented from receiving its own NORM message transmissions. By default, loopback operation is disabled when a NormSession is created.
4.3.12.3. Return Values
This function has no return values.
4.3.13. NormSetFragmentation()
4.3.13.1. Synopsis
#include <normApi.h>
+bool NormSetTOS(NormSessionHandle       sessionHandle,
+                unsigned char           tos);
4.3.12.2. Description
This function specifies the type-of-service (tos) field value used in IP Multicast datagrams generated by NORM for the specified sessionHandle. The IP TOS field value can be used as an indicator that a "flow" of packets may merit special Quality-of-Service (QoS) treatment by network devices. Users should refer to applicable QoS information for their network to determine the expected interpretation and treatment (if any) of packets with explicit TOS marking.
4.3.12.3. Return Values
A return value of true indicates success while a return value of false indicates that the specified tos could not be set. This function will always return true if made before calls to NormStartSender() or NormStartReceiver(). However, those calls may fail if the desired tos value cannot be set.
4.3.13. NormSetLoopback()
4.3.13.1. Synopsis
#include <normApi.h>
 
-bool NormSetFragmentation(NormSessionHandle sessionHandle,
-                          bool              fragmentation);
4.3.13.2. Description
This function sets an underlying socket option that enables or disables IP datagram fragmentation by network intermediate systems according to whether the fragmentation parameter is set to a value of true or false, respectively.  If set to true to enable fragmentation, the DF (don't fragment) bit of the headers of NORM UDP/IP packets sent will be cleared.  Otherwise the DF bit is set and packets will not be fragmented by network devices if they exceed a link Maximum Transmission Unit (MTU) and will instead be dropped.  For IP Multicast destinations, some operating systems may always set the DF bit of transmitted packets, regardless of the setting here and the underlying socket option status.  Typically, the DF bit is set (i.e., fragmentation disabled) by default on most operating systems.  
This call is not currently functional on the Mac OSX system that does not support the needed IP_MTU_DISCOVER or IP_DONTFRAG socket options.
4.3.13.3. Return Values
This function returns true upon success and false upon failure.
4.4. NORM Sender Functions
The functions described in this section apply only to NORM sender operation. Applications may participate strictly as senders or as receivers, or may act as both in the context of a NORM protocol session. The NORM sender is responsible for most parameters pertaining to its transmission of data. This includes transmission rate, data segmentation sizes, FEC coding parameters, stream buffer sizes, etc.
4.4.1. NormStartSender()
4.4.1.1. Synopsis
#include <normApi.h>
+void NormSetLoopback(NormSessionHandle sessionHandle,
+                     bool              loopbackEnable);
4.3.13.2. Description
This function enables or disables loopback operation for the indicated NORM sessionHandle. If loopbackEnable is set to true, loopback operation is enabled which allows the application to receive its own message traffic. Thus, an application which is both actively receiving and sending may receive its own transmissions. Note it is expected that this option would be principally be used for test purposes and that applications would generally not need to transfer data to themselves. If loopbackEnable is false, the application is prevented from receiving its own NORM message transmissions. By default, loopback operation is disabled when a NormSession is created.
4.3.13.3. Return Values
This function has no return values.
4.3.14. NormSetFragmentation()
4.3.14.1. Synopsis
#include <normApi.h>
+
+bool NormSetFragmentation(NormSessionHandle sessionHandle,
+                          bool              fragmentation);
4.3.14.2. Description
This function sets an underlying socket option that enables or disables IP datagram fragmentation by network intermediate systems according to whether the fragmentation parameter is set to a value of true or false, respectively. If set to true to enable fragmentation, the DF (don't fragment) bit of the headers of NORM UDP/IP packets sent will be cleared. Otherwise the DF bit is set and packets will not be fragmented by network devices if they exceed a link Maximum Transmission Unit (MTU) and will instead be dropped. For IP Multicast destinations, some operating systems may always set the DF bit of transmitted packets, regardless of the setting here and the underlying socket option status. Typically, the DF bit is set (i.e., fragmentation disabled) by default on most operating systems.
This call is not currently functional on the Mac OSX system that does not support the needed IP_MTU_DISCOVER or IP_DONTFRAG socket options.
4.3.14.3. Return Values
This function returns true upon success and false upon failure.
4.4. NORM Sender Functions
The functions described in this section apply only to NORM sender operation. Applications may participate strictly as senders or as receivers, or may act as both in the context of a NORM protocol session. The NORM sender is responsible for most parameters pertaining to its transmission of data. This includes transmission rate, data segmentation sizes, FEC coding parameters, stream buffer sizes, etc.
4.4.1. NormStartSender()
4.4.1.1. Synopsis
#include <normApi.h>
 
 bool NormStartSender(NormSessionHandle        sessionHandle,
                      NormSessionId            instanceId,
                      unsigned long            bufferSpace,
                      unsigned short           segmentSize,
                      unsigned char            blockSize,
-                     unsigned char            numParity);
4.4.1.2. Description
The application's participation as a sender within a specified NormSession begins when this function is called. This includes protocol activity such as congestion control and/or group round-trip timing (GRTT) feedback collection and application API activity such as posting of sender-related NormEvent notifications. The parameters required for this function call include:
sessionHandle
This must be a valid NormSessionHandle previously obtained with a call to NormCreateSession().
instanceId
Application-defined value used as the instance_id field of NORM sender messages for the application's participation within a session. Receivers can detect when a sender has terminated and restarted if the application uses different instanceId values when initiating sender operation. For example, a robust application could cache previous instanceId values in non-volatile storage and gracefully recover (without confusing receivers) from a total system shutdown and reboot by using a new instanceId value upon restart.
bufferSpace
This specifies the maximum memory space (in bytes) the NORM protocol engine is allowed to use to buffer any sender calculated FEC segments and repair state for the session. The optimum bufferSpace value is function of the network topology bandwidth*delay product and packet loss characteristics. If the bufferSpace limit is too small, the protocol may operate less efficiently as the sender is required to possibly recalculate FEC parity segments and/or provide less efficient repair transmission strategies (resort to explicit repair) when state is dropped due to constrained buffering resources. However, note the protocol will still provide reliable transfer. A large bufferSpace allocation is safer at the expense of possibly committing more memory resources.
segmentSize
This parameter sets the maximum payload size (in bytes) of NORM sender messages (not including any NORM message header fields). A sender's segmentSize value is also used by receivers to limit the payload content of some feedback messages (e.g. NORM_NACK message content, etc.) generated in response to that sender. Note different senders within a NormSession may use different segmentSize values. Generally, the appropriate segment size to use is dependent upon the types of networks forming the multicast topology, but applications may choose different values for other purposes. Note that application designers MUST account for the size of NORM message headers when selecting a segmentSize. For example, the NORM_DATA message header for a NORM_OBJECT_STREAM with full header extensions is 48 bytes in length. In this case, the UDP payload size of these messages generated by NORM would be up to (48 + segmentSize) bytes.
blockSize
This parameter sets the number of source symbol segments (packets) per coding block, for the systematic Reed-Solomon FEC code used in the current NORM implementation. For traditional systematic block code "(n,k)" nomenclature, the blockSize value corresponds to "k". NORM logically segments transport object data content into coding blocks and the blockSize parameter determines the number of source symbol segments (packets) comprising a single coding block where each source symbol segment is up to segmentSize bytes in length.. A given block's parity symbol segments are calculated using the corresponding set of source symbol segments. The maximum blockSize allowed by the 8-bit Reed-Solomon codes in NORM is 255, with the further limitation that (blockSize + numParity) <= 255.
numParity
This parameter sets the maximum number of parity symbol segments (packets) the sender is willing to calculate per FEC coding block. The parity symbol segments for a block are calculated from the corresponding blockSize source symbol segments. In the "(n,k)" nomenclature mention above, the numParity value corresponds to "n - k". A property of the Reed-Solomon FEC codes used in the current NORM implementation is that one parity segment can fill any one erasure (missing segment (packet)) for a coding block. For a given blockSize, the maximum numParity value is (255 - blockSize). However, note that computational complexity increases significantly with increasing numParity values and applications may wish to be conservative with respect to numParity selection, given anticipated network packet loss conditions and group size scalability concerns. Additional FEC code options may be provided for this NORM implementation in the future with different parameters, capabilities, trade-offs, and computational requirements.
These parameters are currently immutable with respect to a sender's participation within a NormSession. Sender operation must be stopped (see NormStopSender()) and restarted with another call to NormStartSender() if these parameters require alteration. The API may be extended in the future to support additional flexibility here, if required. For example, the NORM protocol "intance_id" field may possibly be leveraged to permit a node to establish multiple virtual presences as a sender within a NormSession in the future. This would allow the sender to provide multiple concurrent streams of transport, with possibly different FEC and other parameters if appropriate within the context of a single NormSession. Again, this extended functionality is not yet supported in this implementation.
4.4.1.3. Return Values
A value of true is returned upon success and false upon failure. The reasons failure may occur include limited system resources or that the network sockets required for communication failed to open or properly configure. (TBD - Provide a NormGetError(NormSessionHandle sessionHandle) function to retrieve a more specific error indication for this and other functions.)
4.4.2. NormStopSender()
4.4.2.1. Synopsis
#include <normApi.h>
+                     unsigned char            numParity);
4.4.1.2. Description
The application's participation as a sender within a specified NormSession begins when this function is called. This includes protocol activity such as congestion control and/or group round-trip timing (GRTT) feedback collection and application API activity such as posting of sender-related NormEvent notifications. The parameters required for this function call include:
sessionHandle
This must be a valid NormSessionHandle previously obtained with a call to NormCreateSession().
instanceId
Application-defined value used as the instance_id field of NORM sender messages for the application's participation within a session. Receivers can detect when a sender has terminated and restarted if the application uses different instanceId values when initiating sender operation. For example, a robust application could cache previous instanceId values in non-volatile storage and gracefully recover (without confusing receivers) from a total system shutdown and reboot by using a new instanceId value upon restart.
bufferSpace
This specifies the maximum memory space (in bytes) the NORM protocol engine is allowed to use to buffer any sender calculated FEC segments and repair state for the session. The optimum bufferSpace value is function of the network topology bandwidth*delay product and packet loss characteristics. If the bufferSpace limit is too small, the protocol may operate less efficiently as the sender is required to possibly recalculate FEC parity segments and/or provide less efficient repair transmission strategies (resort to explicit repair) when state is dropped due to constrained buffering resources. However, note the protocol will still provide reliable transfer. A large bufferSpace allocation is safer at the expense of possibly committing more memory resources.
segmentSize
This parameter sets the maximum payload size (in bytes) of NORM sender messages (not including any NORM message header fields). A sender's segmentSize value is also used by receivers to limit the payload content of some feedback messages (e.g. NORM_NACK message content, etc.) generated in response to that sender. Note different senders within a NormSession may use different segmentSize values. Generally, the appropriate segment size to use is dependent upon the types of networks forming the multicast topology, but applications may choose different values for other purposes. Note that application designers MUST account for the size of NORM message headers when selecting a segmentSize. For example, the NORM_DATA message header for a NORM_OBJECT_STREAM with full header extensions is 48 bytes in length. In this case, the UDP payload size of these messages generated by NORM would be up to (48 + segmentSize) bytes.
blockSize
This parameter sets the number of source symbol segments (packets) per coding block, for the systematic Reed-Solomon FEC code used in the current NORM implementation. For traditional systematic block code "(n,k)" nomenclature, the blockSize value corresponds to "k". NORM logically segments transport object data content into coding blocks and the blockSize parameter determines the number of source symbol segments (packets) comprising a single coding block where each source symbol segment is up to segmentSize bytes in length.. A given block's parity symbol segments are calculated using the corresponding set of source symbol segments. The maximum blockSize allowed by the 8-bit Reed-Solomon codes in NORM is 255, with the further limitation that (blockSize + numParity) <= 255.
numParity
This parameter sets the maximum number of parity symbol segments (packets) the sender is willing to calculate per FEC coding block. The parity symbol segments for a block are calculated from the corresponding blockSize source symbol segments. In the "(n,k)" nomenclature mention above, the numParity value corresponds to "n - k". A property of the Reed-Solomon FEC codes used in the current NORM implementation is that one parity segment can fill any one erasure (missing segment (packet)) for a coding block. For a given blockSize, the maximum numParity value is (255 - blockSize). However, note that computational complexity increases significantly with increasing numParity values and applications may wish to be conservative with respect to numParity selection, given anticipated network packet loss conditions and group size scalability concerns. Additional FEC code options may be provided for this NORM implementation in the future with different parameters, capabilities, trade-offs, and computational requirements.
These parameters are currently immutable with respect to a sender's participation within a NormSession. Sender operation must be stopped (see NormStopSender()) and restarted with another call to NormStartSender() if these parameters require alteration. The API may be extended in the future to support additional flexibility here, if required. For example, the NORM protocol "intance_id" field may possibly be leveraged to permit a node to establish multiple virtual presences as a sender within a NormSession in the future. This would allow the sender to provide multiple concurrent streams of transport, with possibly different FEC and other parameters if appropriate within the context of a single NormSession. Again, this extended functionality is not yet supported in this implementation.
4.4.1.3. Return Values
A value of true is returned upon success and false upon failure. The reasons failure may occur include limited system resources or that the network sockets required for communication failed to open or properly configure. (TBD - Provide a NormGetError(NormSessionHandle sessionHandle) function to retrieve a more specific error indication for this and other functions.)
4.4.2. NormStopSender()
4.4.2.1. Synopsis
#include <normApi.h>
 
 void NormStopSender(NormSessionHandle sessionHandle,
-                    bool              graceful = false);
4.4.2.2. Description
This function terminates the application's participation in a NormSession as a sender. By default, the sender will immediately exit the session identified by the sessionHandle parameter without notifying the receiver set of its intention. However a "graceful shutdown" option, enabled by setting the graceful parameter to true, is provided to terminate sender operation gracefully, notifying the receiver set its pending exit with appropriate protocol messaging. A NormEvent, NORM_LOCAL_SENDER_CLOSED, is dispatched when the graceful shutdown process has completed.
4.4.2.3. Return Values
This function has no return values.
4.4.3. NormSetTxRate()
4.4.3.1. Synopsis
#include <normApi.h>
+                    bool              graceful = false);
4.4.2.2. Description
This function terminates the application's participation in a NormSession as a sender. By default, the sender will immediately exit the session identified by the sessionHandle parameter without notifying the receiver set of its intention. However a "graceful shutdown" option, enabled by setting the graceful parameter to true, is provided to terminate sender operation gracefully, notifying the receiver set its pending exit with appropriate protocol messaging. A NormEvent, NORM_LOCAL_SENDER_CLOSED, is dispatched when the graceful shutdown process has completed.
4.4.2.3. Return Values
This function has no return values.
4.4.3. NormSetTxRate()
4.4.3.1. Synopsis
#include <normApi.h>
 
 void NormSetTxRate(NormSessionHandle sessionHandle,
-                   double            rate);
4.4.3.2. Description
This function sets the transmission rate (in bits per second (bps)) limit used for NormSender transmissions for the given sessionHandle. For fixed-rate transmission of NORM_OBJECT_FILE or NORM_OBJECT_DATA, this limit determines the data rate at which NORM protocol messages and data content are sent. For NORM_OBJECT_STREAM transmissions, this is the maximum rate allowed for transmission (i.e. if the application writes to the stream at a lower rate, a lower average NORM transmission rate will occur). Note that the application will need to consider the overhead of NORM protocol headers when determining an appropriate transmission rate for its purposes. When NORM congestion control is enabled (see NormSetCongestionControl()), the rate set here will be set, but congestion control operation, if enabled, may quickly readjust the transmission rate.
4.4.3.3. Return Values
This function has no return values.
4.4.4. NormGetTxRate()
4.4.4.1. Synopsis
#include <normApi.h>
+                   double            rate);
4.4.3.2. Description
This function sets the transmission rate (in bits per second (bps)) limit used for NormSender transmissions for the given sessionHandle. For fixed-rate transmission of NORM_OBJECT_FILE or NORM_OBJECT_DATA, this limit determines the data rate at which NORM protocol messages and data content are sent. For NORM_OBJECT_STREAM transmissions, this is the maximum rate allowed for transmission (i.e. if the application writes to the stream at a lower rate, a lower average NORM transmission rate will occur). Note that the application will need to consider the overhead of NORM protocol headers when determining an appropriate transmission rate for its purposes. When NORM congestion control is enabled (see NormSetCongestionControl()), the rate set here will be set, but congestion control operation, if enabled, may quickly readjust the transmission rate.
4.4.3.3. Return Values
This function has no return values.
4.4.4. NormGetTxRate()
4.4.4.1. Synopsis
#include <normApi.h>
 
-double NormGetTxRate(NormSessionHandle sessionHandle);
4.4.4.2. Description
This function retrieves the current sender transmission rate in units of bits per second (bps) for the given sessionHandle. When NORM congestion control is enabled (see NormSetCongestionControl()), this reflects the current rate set (or suggested) by NORM congestion control operation. Otherwise, this returns the rate that was set with the NormSetTxRate() call.
4.4.4.3. Return Values
This function returns the sender transmission rate in units of bits per second (bps).
4.4.5. NormSetTxSocketBuffer()
4.4.5.1. Synopsis
#include <normApi.h>
+double NormGetTxRate(NormSessionHandle sessionHandle);
4.4.4.2. Description
This function retrieves the current sender transmission rate in units of bits per second (bps) for the given sessionHandle. When NORM congestion control is enabled (see NormSetCongestionControl()), this reflects the current rate set (or suggested) by NORM congestion control operation. Otherwise, this returns the rate that was set with the NormSetTxRate() call.
4.4.4.3. Return Values
This function returns the sender transmission rate in units of bits per second (bps).
4.4.5. NormSetTxSocketBuffer()
4.4.5.1. Synopsis
#include <normApi.h>
 
 bool NormSetTxSocketBuffer(NormSessionHandle sessionHandle,
-                           unsigned int      bufferSize);
4.4.5.2. Description
This function can be used to set a non-default socket buffer size for the UDP socket used by the specified NORM sessionHandle for data transmission. The bufferSize parameter specifies the desired socket buffer size in bytes. Large transmit socket buffer sizes may be necessary to achieve high transmission rates when NORM, as a user-space process, is unable to precisely time its packet transmissions. Similarly, NORM receivers may need to set large receive socket buffer sizes to achieve successful, sustained high data rate reception (see NormSetRxSocketBuffer()). Typically, it is more important to set the receive socket buffer size (see NormSetRxSocketBuffer()) as this maintains reliability (i.e. by avoiding receive socket buffer overflow) at high data rates while setting a larger transmit socket buffer size allows higher average transmission rates to be achieved.
4.4.5.3. Return Values
This function returns true upon success and false upon failure. Possible failure modes include an invalid sessionHandle parameter, a call to NormStartReceiver() or NormStartSender() has not yet been made for the session, or an invalid bufferSize was given. Note some operating systems may require additional system configuration to use non-standard socket buffer sizes.
4.4.6. NormSetFlowControl()
4.4.6.1. Synopsis
#include <normApi.h>
+                           unsigned int      bufferSize);
4.4.5.2. Description
This function can be used to set a non-default socket buffer size for the UDP socket used by the specified NORM sessionHandle for data transmission. The bufferSize parameter specifies the desired socket buffer size in bytes. Large transmit socket buffer sizes may be necessary to achieve high transmission rates when NORM, as a user-space process, is unable to precisely time its packet transmissions. Similarly, NORM receivers may need to set large receive socket buffer sizes to achieve successful, sustained high data rate reception (see NormSetRxSocketBuffer()). Typically, it is more important to set the receive socket buffer size (see NormSetRxSocketBuffer()) as this maintains reliability (i.e. by avoiding receive socket buffer overflow) at high data rates while setting a larger transmit socket buffer size allows higher average transmission rates to be achieved.
4.4.5.3. Return Values
This function returns true upon success and false upon failure. Possible failure modes include an invalid sessionHandle parameter, a call to NormStartReceiver() or NormStartSender() has not yet been made for the session, or an invalid bufferSize was given. Note some operating systems may require additional system configuration to use non-standard socket buffer sizes.
4.4.6. NormSetFlowControl()
4.4.6.1. Synopsis
#include <normApi.h>
 
 void NormSetFlowControl(NormSessionHandle sessionHandle,
-                        double            flowControlFactor);
4.4.6.2. Description
This function controls a scaling factor that is used for sender timer-based flow control for the the specified NORM sessionHandle. Timer-based flow control works by preventing the NORM sender application from enqueueing new transmit objects or stream data that would purge "old" objects or stream data when there has been recent NACK activity for those old objects or data. If the flowControlFactor is set to ZERO, then the flow control mechanism is effectively disabled. Larger flowControlFactor values enforce more robust flow control by forcing the sender to maintain state longer, but then larger transmit buffer, stream buffer, transmit cache bounds and receive cache limits (see NormStartSender(), NormStreamOpen(), NormSetTxCacheBounds(), and NormSetRxCacheLimit(), respectively) may be needed to maintain throughput in larger <delay*bandwidth, loss> conditions. Effectively, a larger flowControlFactor can favor reliability over throughput when buffer-constrained.
The flowControlFactor is used to compute a delay time for when a sender buffered object (or block of stream data) may be released (i.e. purged) after transmission or applicable NACKs reception. The delay time function is:
flowControlDelay = flowControlFactor * GRTT * (backoffFactor + 1)
where the "GRTT" is the sender's advertised GRTT estimate and the backoffFactor is the sender's configured timer-based feedback scaling factor.
The default value (when this function is not called) of the flowControlFactor is 2.0. Note that a NORM application can also implement more explicit, deterministic flow control through use of the NormSetWatermark() API call, potentially even requiring positive acknowledgement of older data before enqueueing new data. Note that using the NormSetWatermark() API call with a NORM_NODE_NONE member in acking node list to force a "full" watermark flush is somewhat equivalent to timer-based flow control with a flowControlFactor equal to 2.0 * txRobustFactor.
If such explicit flow control is implemented by the application, then a reduced flowControlFactor (or even ZERO) may be used. If "push mode" is enabled for a NORM_OBJECT_STREAM (see NormStreamSetPushEnable()), then flow control has no effect for the stream.
4.4.6.3. Return Values
This function has no return values.
4.4.7. NormSetCongestionControl()
4.4.7.1. Synopsis
#include <normApi.h>
+                        double            flowControlFactor);
4.4.6.2. Description
This function controls a scaling factor that is used for sender timer-based flow control for the the specified NORM sessionHandle. Timer-based flow control works by preventing the NORM sender application from enqueueing new transmit objects or stream data that would purge "old" objects or stream data when there has been recent NACK activity for those old objects or data. If the flowControlFactor is set to ZERO, then the flow control mechanism is effectively disabled. Larger flowControlFactor values enforce more robust flow control by forcing the sender to maintain state longer, but then larger transmit buffer, stream buffer, transmit cache bounds and receive cache limits (see NormStartSender(), NormStreamOpen(), NormSetTxCacheBounds(), and NormSetRxCacheLimit(), respectively) may be needed to maintain throughput in larger <delay*bandwidth, loss> conditions. Effectively, a larger flowControlFactor can favor reliability over throughput when buffer-constrained.
The flowControlFactor is used to compute a delay time for when a sender buffered object (or block of stream data) may be released (i.e. purged) after transmission or applicable NACKs reception. The delay time function is:
flowControlDelay = flowControlFactor * GRTT * (backoffFactor + 1)
where the "GRTT" is the sender's advertised GRTT estimate and the backoffFactor is the sender's configured timer-based feedback scaling factor.
The default value (when this function is not called) of the flowControlFactor is 2.0. Note that a NORM application can also implement more explicit, deterministic flow control through use of the NormSetWatermark() API call, potentially even requiring positive acknowledgement of older data before enqueueing new data. Note that using the NormSetWatermark() API call with a NORM_NODE_NONE member in acking node list to force a "full" watermark flush is somewhat equivalent to timer-based flow control with a flowControlFactor equal to 2.0 * txRobustFactor.
If such explicit flow control is implemented by the application, then a reduced flowControlFactor (or even ZERO) may be used. If "push mode" is enabled for a NORM_OBJECT_STREAM (see NormStreamSetPushEnable()), then flow control has no effect for the stream.
4.4.6.3. Return Values
This function has no return values.
4.4.7. NormSetCongestionControl()
4.4.7.1. Synopsis
#include <normApi.h>
 
 void NormSetCongestionControl(NormSessionHandle sessionHandle,
                               bool              enable,
-                              bool              adjustRate = true);
4.4.7.2. Description
This function enables (or disables) the NORM sender congestion control operation for the session designated by the sessionHandle parameter. For best operation, this function should be called before the call to NormStartSender() is made, but congestion control operation can be dynamically enabled/disabled during the course of sender operation. If the value of the enable parameter is true, congestion control operation is enabled while it is disabled for enable equal to false. When congestion control operation is enabled, the NORM sender automatically adjusts its transmission rate based on feedback from receivers. If bounds on transmission rate have been set (see NormSetTxRateBounds()) the rate adjustment will remain within the set bounds. The application will be notified of any changes to the sender transmission rate via a NormEvent of type NORM_TX_RATE_CHANGED.
The rate set by NormSetTxRate() has no effect when congestion control operation is enabled, unless the adjustRate parameter here is set to false. When the adjustRate parameter is set to false, the NORM Congestion Control operates as usual, with feedback collected from the receiver set and the "current limiting receiver" identified, except that no actual adjustment is made to the sender's transmission rate. I.e., the transmission rate that was set by NormSetTxRate() is observed by the sender regardless of the feedback received. The NORM_TX_RATE_CHANGED notification will still occur as if the rate were being adjusted and the value returned by NormGetTxRate() reflects the rate that would have been used had the adjustRate parameter been enabled even though no actual rate change has occurred. The purpose of this variation of NORM Congestion Control operation is to allow applications to get a "suggested" rate from the NORM-CC mechanism. But, it is important to note that this "suggested" rate may or may not be appropriate since the operation of the NORM-CC algorithm is somewhat dependent on the associated NORM sender load on the network. For example, the "suggested" rate may be artificially high if the sender application has not been correspondingly setting the rate and actively transmitting data at that rate. This optional mode of operation is provided for EXPERIMENTAL purposes and is NOT RECOMMENDED for typical use of NORM.
NORM's congestion algorithm provides rate adjustment to fairly compete for available network bandwidth with other TCP, NORM, or similarly governed traffic flows.
(TBD - Describe the NormSetEcnSupport() function as this experimental option matures.)
4.4.7.3. Return Values
This function has no return values.
4.4.8. NormSetTxRateBounds()
4.4.8.1. Synopsis
#include <normApi.h>
+                              bool              adjustRate = true);
4.4.7.2. Description
This function enables (or disables) the NORM sender congestion control operation for the session designated by the sessionHandle parameter. For best operation, this function should be called before the call to NormStartSender() is made, but congestion control operation can be dynamically enabled/disabled during the course of sender operation. If the value of the enable parameter is true, congestion control operation is enabled while it is disabled for enable equal to false. When congestion control operation is enabled, the NORM sender automatically adjusts its transmission rate based on feedback from receivers. If bounds on transmission rate have been set (see NormSetTxRateBounds()) the rate adjustment will remain within the set bounds. The application will be notified of any changes to the sender transmission rate via a NormEvent of type NORM_TX_RATE_CHANGED.
The rate set by NormSetTxRate() has no effect when congestion control operation is enabled, unless the adjustRate parameter here is set to false. When the adjustRate parameter is set to false, the NORM Congestion Control operates as usual, with feedback collected from the receiver set and the "current limiting receiver" identified, except that no actual adjustment is made to the sender's transmission rate. I.e., the transmission rate that was set by NormSetTxRate() is observed by the sender regardless of the feedback received. The NORM_TX_RATE_CHANGED notification will still occur as if the rate were being adjusted and the value returned by NormGetTxRate() reflects the rate that would have been used had the adjustRate parameter been enabled even though no actual rate change has occurred. The purpose of this variation of NORM Congestion Control operation is to allow applications to get a "suggested" rate from the NORM-CC mechanism. But, it is important to note that this "suggested" rate may or may not be appropriate since the operation of the NORM-CC algorithm is somewhat dependent on the associated NORM sender load on the network. For example, the "suggested" rate may be artificially high if the sender application has not been correspondingly setting the rate and actively transmitting data at that rate. This optional mode of operation is provided for EXPERIMENTAL purposes and is NOT RECOMMENDED for typical use of NORM.
NORM's congestion algorithm provides rate adjustment to fairly compete for available network bandwidth with other TCP, NORM, or similarly governed traffic flows.
(TBD - Describe the NormSetEcnSupport() function as this experimental option matures.)
4.4.7.3. Return Values
This function has no return values.
4.4.8. NormSetTxRateBounds()
4.4.8.1. Synopsis
#include <normApi.h>
 
 bool NormSetTxRateBounds(NormSessionHandle sessionHandle,
                                double            rateMin,
-                               double            rateMax);
4.4.8.2. Description
This function sets the range of sender transmission rates within which the NORM congestion control algorithm is allowed to operate for the given sessionHandle. By default, the NORM congestion control algorithm operates with no lower or upper bound on its rate adjustment. This function allows this to be limited where rateMin corresponds to the minimum transmission rate (bps) and rateMax corresponds to the maximum transmission rate. One or both of these parameters may be set to values less than zero to remove one or both bounds. For example, the call "NormSetTxRateBounds(session, -1.0, 64000.0)" will set an upper limit of 64 kbps for the sender transmission rate with no lower bound. These rate bounds apply only when congestion control operation is enabled (see NormSetCongestionControl()). If the current congestion control rate falls outside of the specified bounds, the sender transmission rate will be adjusted to stay within the set bounds.
4.4.8.3. Return Values
This function returns true upon success. If both rateMin and rateMax are greater than or equal to zero, but (rateMax < rateMin), the rate bounds will remain unset or unchanged and the function will return false.
4.4.9. NormSetTxCacheBounds()
4.4.9.1. Synopsis
#include <normApi.h>
+                               double            rateMax);
4.4.8.2. Description
This function sets the range of sender transmission rates within which the NORM congestion control algorithm is allowed to operate for the given sessionHandle. By default, the NORM congestion control algorithm operates with no lower or upper bound on its rate adjustment. This function allows this to be limited where rateMin corresponds to the minimum transmission rate (bps) and rateMax corresponds to the maximum transmission rate. One or both of these parameters may be set to values less than zero to remove one or both bounds. For example, the call "NormSetTxRateBounds(session, -1.0, 64000.0)" will set an upper limit of 64 kbps for the sender transmission rate with no lower bound. These rate bounds apply only when congestion control operation is enabled (see NormSetCongestionControl()). If the current congestion control rate falls outside of the specified bounds, the sender transmission rate will be adjusted to stay within the set bounds.
4.4.8.3. Return Values
This function returns true upon success. If both rateMin and rateMax are greater than or equal to zero, but (rateMax < rateMin), the rate bounds will remain unset or unchanged and the function will return false.
4.4.9. NormSetTxCacheBounds()
4.4.9.1. Synopsis
#include <normApi.h>
 
 void NormSetTxCacheBounds(NormSessionHandle sessionHandle,
                                 NormSize          sizeMax,
                                 unsigned int      countMin,
-                                unsigned int      countMax);
4.4.9.2. Description
This function sets limits that define the number and total size of pending transmit objects a NORM sender will allow to be enqueued by the application. Setting these bounds to large values means the NORM protocol engine will keep history and state for previously transmitted objects for a larger interval of time (depending upon the transmission rate) when the application is actively enqueueing additional objects in response to NORM_TX_QUEUE_EMPTY notifications. This can allow more time for receivers suffering degraded network conditions to make repair requests before the sender "purges" older objects from its "transmit cache" when new objects are enqueued. A NORM_TX_OBJECT_PURGED notification is issued when the enqueuing of a new transmit object causes the NORM transmit cache to overflow, indicating the NORM sender no longer needs to reference the designated old transmit object and the application is free to release related resources as needed.
The sizeMax parameter sets the maximum total size, in bytes, of enqueued objects allowed, providing the constraints of the countMin and countMax parameters are met. The countMin parameter sets the minimum number of objects the application may enqueue, regardless of the objects' sizes and the sizeMax value. For example, the default sizeMax value is 20 Mbyte and the default countMin is 8, thus allowing the application to always have at least 8 pending objects enqueued for transmission if it desires, even if their total size is greater than 20 Mbyte. Similarly, the countMax parameter sets a ceiling on how many objects may be enqueued, regardless of their total sizes with respect to the sizeMax setting. For example, the default countMax value is 256, which means the application is never allowed to have more than 256 objects pending transmission enqueued, even if they are 256 very small objects. Note that countMax must be greater than or equal to countMin and countMin is recommended to be at least two.
Note that in the case of NORM_OBJECT_FILE objects, some operating systems impose limits (e.g. 256) on how many open files a process may have at one time and it may be appropriate to limit the countMax value accordingly. In other cases, a large countMin or countMax may be desired to allow the NORM sender to act as virtual cache of files or other data available for reliable transmission. Future iterations of the NRL NORM implementation may support alternative NORM receiver "group join" policies that would allow the receivers to request transmission of cached content.
The utility of the NormRequeueObject() API call also depends on the parameters set by this function. The NormRequeueObject() call will only succeed when the given objectHandle corresponds to an object maintained in the NORM senders "transmit cache".
4.4.9.3. Return Values
This function has no return value.
4.4.10. NormSetAutoParity()
4.4.10.1. Synopsis
#include <normApi.h>
+                                unsigned int      countMax);
4.4.9.2. Description
This function sets limits that define the number and total size of pending transmit objects a NORM sender will allow to be enqueued by the application. Setting these bounds to large values means the NORM protocol engine will keep history and state for previously transmitted objects for a larger interval of time (depending upon the transmission rate) when the application is actively enqueueing additional objects in response to NORM_TX_QUEUE_EMPTY notifications. This can allow more time for receivers suffering degraded network conditions to make repair requests before the sender "purges" older objects from its "transmit cache" when new objects are enqueued. A NORM_TX_OBJECT_PURGED notification is issued when the enqueuing of a new transmit object causes the NORM transmit cache to overflow, indicating the NORM sender no longer needs to reference the designated old transmit object and the application is free to release related resources as needed.
The sizeMax parameter sets the maximum total size, in bytes, of enqueued objects allowed, providing the constraints of the countMin and countMax parameters are met. The countMin parameter sets the minimum number of objects the application may enqueue, regardless of the objects' sizes and the sizeMax value. For example, the default sizeMax value is 20 Mbyte and the default countMin is 8, thus allowing the application to always have at least 8 pending objects enqueued for transmission if it desires, even if their total size is greater than 20 Mbyte. Similarly, the countMax parameter sets a ceiling on how many objects may be enqueued, regardless of their total sizes with respect to the sizeMax setting. For example, the default countMax value is 256, which means the application is never allowed to have more than 256 objects pending transmission enqueued, even if they are 256 very small objects. Note that countMax must be greater than or equal to countMin and countMin is recommended to be at least two.
Note that in the case of NORM_OBJECT_FILE objects, some operating systems impose limits (e.g. 256) on how many open files a process may have at one time and it may be appropriate to limit the countMax value accordingly. In other cases, a large countMin or countMax may be desired to allow the NORM sender to act as virtual cache of files or other data available for reliable transmission. Future iterations of the NRL NORM implementation may support alternative NORM receiver "group join" policies that would allow the receivers to request transmission of cached content.
The utility of the NormRequeueObject() API call also depends on the parameters set by this function. The NormRequeueObject() call will only succeed when the given objectHandle corresponds to an object maintained in the NORM senders "transmit cache".
4.4.9.3. Return Values
This function has no return value.
4.4.10. NormSetAutoParity()
4.4.10.1. Synopsis
#include <normApi.h>
 
 void NormSetAutoParity(NormSessionHandle sessionHandle,
-                       unsigned char     autoParity);
4.4.10.2. Description
This function sets the quantity of proactive "auto parity" NORM_DATA messages sent at the end of each FEC coding block. By default (i.e., autoParity = 0), FEC content is sent only in response to repair requests (NACKs) from receivers. But, by setting a non-zero value for autoParity, the sender can automatically accompany each coding block of transport object source data segments ((NORM_DATA messages) with the set number of FEC segments. The number of source symbol messages (segments) per FEC coding block is determined by the blockSize parameter used when NormStartSender() was called for the given sessionHandle.
The use of proactively-sent "auto parity" may eliminate the need for any receiver NACKing to achieve reliable transfer in networks with low packet loss. However, note that the quantity of "auto parity" set adds overhead to transport object transmission. In networks with a predictable level of packet loss and potentially large round-trip times, the use of "auto parity" may allow lower latency in the reliable delivery process. Also, its use may contribute to a smaller amount of receiver feedback as only receivers with exceptional packet loss may need to NACK for additional repair content.
The value of autoParity set must be less than or equal to the numParity parameter set when NormStartSender() was called for the given sessionHandle.
4.4.10.3. Return Values
This function has no return values.
4.4.11. NormGetGrttEstimate()
4.4.11.1. Synopsis
#include <normApi.h>
+                       unsigned char     autoParity);
4.4.10.2. Description
This function sets the quantity of proactive "auto parity" NORM_DATA messages sent at the end of each FEC coding block. By default (i.e., autoParity = 0), FEC content is sent only in response to repair requests (NACKs) from receivers. But, by setting a non-zero value for autoParity, the sender can automatically accompany each coding block of transport object source data segments ((NORM_DATA messages) with the set number of FEC segments. The number of source symbol messages (segments) per FEC coding block is determined by the blockSize parameter used when NormStartSender() was called for the given sessionHandle.
The use of proactively-sent "auto parity" may eliminate the need for any receiver NACKing to achieve reliable transfer in networks with low packet loss. However, note that the quantity of "auto parity" set adds overhead to transport object transmission. In networks with a predictable level of packet loss and potentially large round-trip times, the use of "auto parity" may allow lower latency in the reliable delivery process. Also, its use may contribute to a smaller amount of receiver feedback as only receivers with exceptional packet loss may need to NACK for additional repair content.
The value of autoParity set must be less than or equal to the numParity parameter set when NormStartSender() was called for the given sessionHandle.
4.4.10.3. Return Values
This function has no return values.
4.4.11. NormGetGrttEstimate()
4.4.11.1. Synopsis
#include <normApi.h>
 
-double NormGetGrttEstimate(NormSessionHandle sessionHandle);
4.4.11.2. Description
This function returns the sender's current estimate(in seconds) of group round-trip timing (GRTT) for the given NORM session. This function may be useful for applications to leverage for other purposes the assessment of round-trip timing made by the NORM protocol engine. For example, an application may scale its own timeouts based on connectivity delays among participants in a NORM session. Note that the NORM_GRTT_UPDATED event is posted (see NormGetNextEvent()) by the NORM protocol engine to indicate when changes in the local sender or remote senders' GRTT estimate occurs.
4.4.11.3. Return Values
This function returns the current sender group round-trip timing (GRTT) estimate (in units of seconds). A value of -1.0 is returned if an invalid session value is provided.
4.4.12. NormSetGrttEstimate()
4.4.12.1. Synopsis
#include <normApi.h>
+double NormGetGrttEstimate(NormSessionHandle sessionHandle);
4.4.11.2. Description
This function returns the sender's current estimate(in seconds) of group round-trip timing (GRTT) for the given NORM session. This function may be useful for applications to leverage for other purposes the assessment of round-trip timing made by the NORM protocol engine. For example, an application may scale its own timeouts based on connectivity delays among participants in a NORM session. Note that the NORM_GRTT_UPDATED event is posted (see NormGetNextEvent()) by the NORM protocol engine to indicate when changes in the local sender or remote senders' GRTT estimate occurs.
4.4.11.3. Return Values
This function returns the current sender group round-trip timing (GRTT) estimate (in units of seconds). A value of -1.0 is returned if an invalid session value is provided.
4.4.12. NormSetGrttEstimate()
4.4.12.1. Synopsis
#include <normApi.h>
 
 void NormSetGrttEstimate(NormSessionHandle sessionHandle,
-                         double            grtt);
4.4.12.2. Description
This function sets the sender's estimate of group round-trip time (GRTT) (in units of seconds) for the given NORM sessionHandle. This function is expected to most typically used to initialize the sender's GRTT estimate prior to the call to NormStartSender() when the application has a priori confidence that the default initial GRTT value of 0.5 second is inappropriate. The sender GRTT estimate will be updated during normal sender protocol operation after sender startup or if this call is made while sender operation is active. For experimental purposes (or very special application needs), this API provides a mechanism to control or disable the sender GRTT update process (see NormSetGrttProbingMode()). The grtt value (in seconds) will be limited to the maximum GRTT as set (see NormSetGrttMax()) or the default maximum of 10 seconds.
The sender GRTT is advertised to the receiver group and is used to scale various NORM protocol timers. The default NORM GRTT estimation process dynamically measures round-trip timing to determine an appropriate operating value. An overly-large GRTT estimate can introduce additional latency into the reliability process (resulting in a larger virtual delay*bandwidth product for the protocol and potentially requiring more buffer space to maintain reliability). An overly-small GRTT estimate may introduce the potential for feedback implosion, limiting the scalability of group size.
Also note that the advertised GRTT estimate can also be limited by transmission rate. When the sender transmission rate is low, the GRTT is also governed to a lower bound of the nominal packet transmission interval (i.e., 1/txRate). This maintains the "event driven" nature of the NORM protocol with respect to receiver reception of NORM sender data and commands.
4.4.12.3. Return Values
This function has no return values.
4.4.13. NormSetGrttMax()
4.4.13.1. Synopsis
#include <normApi.h>
+                         double            grtt);
4.4.12.2. Description
This function sets the sender's estimate of group round-trip time (GRTT) (in units of seconds) for the given NORM sessionHandle. This function is expected to most typically used to initialize the sender's GRTT estimate prior to the call to NormStartSender() when the application has a priori confidence that the default initial GRTT value of 0.5 second is inappropriate. The sender GRTT estimate will be updated during normal sender protocol operation after sender startup or if this call is made while sender operation is active. For experimental purposes (or very special application needs), this API provides a mechanism to control or disable the sender GRTT update process (see NormSetGrttProbingMode()). The grtt value (in seconds) will be limited to the maximum GRTT as set (see NormSetGrttMax()) or the default maximum of 10 seconds.
The sender GRTT is advertised to the receiver group and is used to scale various NORM protocol timers. The default NORM GRTT estimation process dynamically measures round-trip timing to determine an appropriate operating value. An overly-large GRTT estimate can introduce additional latency into the reliability process (resulting in a larger virtual delay*bandwidth product for the protocol and potentially requiring more buffer space to maintain reliability). An overly-small GRTT estimate may introduce the potential for feedback implosion, limiting the scalability of group size.
Also note that the advertised GRTT estimate can also be limited by transmission rate. When the sender transmission rate is low, the GRTT is also governed to a lower bound of the nominal packet transmission interval (i.e., 1/txRate). This maintains the "event driven" nature of the NORM protocol with respect to receiver reception of NORM sender data and commands.
4.4.12.3. Return Values
This function has no return values.
4.4.13. NormSetGrttMax()
4.4.13.1. Synopsis
#include <normApi.h>
 
 void NormSetGrttMax(NormSessionHandle sessionHandle,
-                    double            grttMax);
4.4.13.2. Description
This function sets the sender's maximum advertised GRTT value for the given NORM sessionHandle. The grttMax parameter, in units of seconds, limits the GRTT used by the group for scaling protocol timers, regardless of larger measured round trip times. The default maximum for the NRL NORM library is 10 seconds. See the NormSetGrttEstimate() function description for the purpose of the NORM GRTT measurement process.
4.4.13.3. Return Values
This function has no return values.
4.4.14. NormSetGrttProbingMode()
4.4.14.1. Synopsis
#include <normApi.h>
+                    double            grttMax);
4.4.13.2. Description
This function sets the sender's maximum advertised GRTT value for the given NORM sessionHandle. The grttMax parameter, in units of seconds, limits the GRTT used by the group for scaling protocol timers, regardless of larger measured round trip times. The default maximum for the NRL NORM library is 10 seconds. See the NormSetGrttEstimate() function description for the purpose of the NORM GRTT measurement process.
4.4.13.3. Return Values
This function has no return values.
4.4.14. NormSetGrttProbingMode()
4.4.14.1. Synopsis
#include <normApi.h>
 
 void NormSetGrttProbingMode(NormSessionHandle sessionHandle,
-                            NormProbingMode   probingMode);
4.4.14.2. Description
This function sets the sender's mode of probing for round trip timing measurement responses from the receiver set for the given NORM sessionHandle. Possible values for the probingMode parameter include NORM_PROBE_NONE, NORM_PROBE_PASSIVE, and NORM_PROBE_ACTIVE. The default probing mode is NORM_PROBE_ACTIVE. In this mode, the receiver set explicitly acknowledges NORM sender GRTT probes ((NORM_CMD(CC) messages) with NORM_ACK responses that are group-wise suppressed. Note that NORM receivers also will include their response to GRTT probing piggy-backed on any NORM_NACK messages sent in this mode as well to minimize feedback.
Note that the NORM_PROBE_ACTIVE probing mode is required and automatically set when NORM congestion control operation is enabled (see NormSetCongestionControl()). Thus, when congestion control is enabled, the NormSetGrttProbingMode() function has no effect.
If congestion control operation is not enabled, the NORM application may elect to reduce the volume of feedback traffic by setting the probingMode to NORM_PROBE_PASSIVE. Here, the NORM sender still transmits NORM_CMD(CC) probe messages multiplexed with its data transmission, but the receiver set does not explicitly acknowledge these probes. Instead the receiver set is limited to opportunistically piggy-backing responses when NORM_NACK messages are generated. Note that this may, in some cases, introduce some opportunity for bursts of large volume receiver feedback when the sender's estimate of GRTT is incorrect due to the reduced probing feedback. But, in some controlled network environments, this option for passive probing may provide some benefits in reducing protocol overhead.
Finally, the probingMode can be set to NORM_PROBE_NONE to eliminate the overhead (and benefits) of NORM GRTT measurement entirely. In this case, the sender application must explicitly set its estimate of GRTT using the NormSetGrttEstimate() function. See this function for a description of the purpose of the NORM GRTT measurement.
4.4.14.3. Return Values
This function has no return values.
4.4.15. NormSetGrttProbingInterval()
4.4.15.1. Synopsis
#include <normApi.h>
+                            NormProbingMode   probingMode);
4.4.14.2. Description
This function sets the sender's mode of probing for round trip timing measurement responses from the receiver set for the given NORM sessionHandle. Possible values for the probingMode parameter include NORM_PROBE_NONE, NORM_PROBE_PASSIVE, and NORM_PROBE_ACTIVE. The default probing mode is NORM_PROBE_ACTIVE. In this mode, the receiver set explicitly acknowledges NORM sender GRTT probes ((NORM_CMD(CC) messages) with NORM_ACK responses that are group-wise suppressed. Note that NORM receivers also will include their response to GRTT probing piggy-backed on any NORM_NACK messages sent in this mode as well to minimize feedback.
Note that the NORM_PROBE_ACTIVE probing mode is required and automatically set when NORM congestion control operation is enabled (see NormSetCongestionControl()). Thus, when congestion control is enabled, the NormSetGrttProbingMode() function has no effect.
If congestion control operation is not enabled, the NORM application may elect to reduce the volume of feedback traffic by setting the probingMode to NORM_PROBE_PASSIVE. Here, the NORM sender still transmits NORM_CMD(CC) probe messages multiplexed with its data transmission, but the receiver set does not explicitly acknowledge these probes. Instead the receiver set is limited to opportunistically piggy-backing responses when NORM_NACK messages are generated. Note that this may, in some cases, introduce some opportunity for bursts of large volume receiver feedback when the sender's estimate of GRTT is incorrect due to the reduced probing feedback. But, in some controlled network environments, this option for passive probing may provide some benefits in reducing protocol overhead.
Finally, the probingMode can be set to NORM_PROBE_NONE to eliminate the overhead (and benefits) of NORM GRTT measurement entirely. In this case, the sender application must explicitly set its estimate of GRTT using the NormSetGrttEstimate() function. See this function for a description of the purpose of the NORM GRTT measurement.
4.4.14.3. Return Values
This function has no return values.
4.4.15. NormSetGrttProbingInterval()
4.4.15.1. Synopsis
#include <normApi.h>
 
 void NormSetGrttProbingInterval(NormSessionHandle sessionHandle,
                                 double            intervalMin,
-                                double            intervalMax);
4.4.15.2. Description
This function controls the sender GRTT measurement and estimation process for the given NORM sessionHandle. The NORM sender multiplexes periodic transmission of NORM_CMD(CC) messages with its ongoing data transmission or when data transmission is idle. When NORM congestion control operation is enabled, these probes are sent once per RTT of the current limiting receiver (with respect to congestion control rate). In this case the intervalMin and intervalMax parameters (in units of seconds) control the rate at which the sender's estimate of GRTT is updated. At session start, the estimate is updated at intervalMin and the update interval time is doubled until intervalMax is reached. This dynamic allows for a rapid initial estimation of GRTT and a slower, steady-state update of GRTT. When congestion control is disabled and NORM GRTT probing is enabled ((NORM_PROBE_ACTIVE or NORM_PROBE_PASSIVE) the intervalMin and intervalMax values also determine the rate at which NORM_CMD(CC) probes are transmitted by the sender. Thus by setting larger values for intervalMin and intervalMax, the NORM sender application can reduce the overhead of the GRTT measurement process. However, this also reduces the ability of NORM to adapt to changes in GRTT.
The default NORM GRTT intervalMin and intervalMax values, i.e., when this call is not made, are 1.0 second and 30.0 seconds, respectively.
4.4.15.3. Return Values
This function has no return values.
4.4.16. NormSetBackoffFactor()
4.4.16.1. Synopsis
#include <normApi.h>
+                                double            intervalMax);
4.4.15.2. Description
This function controls the sender GRTT measurement and estimation process for the given NORM sessionHandle. The NORM sender multiplexes periodic transmission of NORM_CMD(CC) messages with its ongoing data transmission or when data transmission is idle. When NORM congestion control operation is enabled, these probes are sent once per RTT of the current limiting receiver (with respect to congestion control rate). In this case the intervalMin and intervalMax parameters (in units of seconds) control the rate at which the sender's estimate of GRTT is updated. At session start, the estimate is updated at intervalMin and the update interval time is doubled until intervalMax is reached. This dynamic allows for a rapid initial estimation of GRTT and a slower, steady-state update of GRTT. When congestion control is disabled and NORM GRTT probing is enabled ((NORM_PROBE_ACTIVE or NORM_PROBE_PASSIVE) the intervalMin and intervalMax values also determine the rate at which NORM_CMD(CC) probes are transmitted by the sender. Thus by setting larger values for intervalMin and intervalMax, the NORM sender application can reduce the overhead of the GRTT measurement process. However, this also reduces the ability of NORM to adapt to changes in GRTT.
The default NORM GRTT intervalMin and intervalMax values, i.e., when this call is not made, are 1.0 second and 30.0 seconds, respectively.
4.4.15.3. Return Values
This function has no return values.
4.4.16. NormSetBackoffFactor()
4.4.16.1. Synopsis
#include <normApi.h>
 
 void NormSetBackoffFactor(NormSessionHandle sessionHandle,
-                          double            backoffFactor);
4.4.16.2. Description
This function sets the sender's "backoff factor" for the given sessionHandle. The backoffFactor (in units of seconds) is used to scale various timeouts related to the NACK repair process. The sender advertises its backoffFactor setting to the receiver group in NORM protocol message headers. The default backoffFactor for NORM sessions is 4.0 seconds. The backoffFactor is used to determine the maximum time that receivers may delay NACK transmissions (and other feedback messages) as part of NORM's probabilistic feedback suppression technique. For example, the maximum NACK delay time is backoffFactor*GRTT. Thus a large backoffFactor value introduces latency into the NORM repair process. However, a small backoffFactor value causes feedback suppression to be less effective and increases the risk of feedback implosion for large receiver group sizes.
The default setting of 4.0 provides reasonable feedback suppression for moderate to large group sizes when multicast feedback is possible. The NORM specification recommends a backoffFactor value of 6.0 when unicast feedback is used. However, for demanding applications (with respect to repair latency) when group sizes are modest, a small (even 0.0) backoffFactor value can be specified to reduce the latency of reliable data delivery.
4.4.16.3. Return Values
This function has no return values.
4.4.17. NormSetGroupSize()
4.4.17.1. Synopsis
#include <normApi.h>
+                          double            backoffFactor);
4.4.16.2. Description
This function sets the sender's "backoff factor" for the given sessionHandle. The backoffFactor (in units of seconds) is used to scale various timeouts related to the NACK repair process. The sender advertises its backoffFactor setting to the receiver group in NORM protocol message headers. The default backoffFactor for NORM sessions is 4.0 seconds. The backoffFactor is used to determine the maximum time that receivers may delay NACK transmissions (and other feedback messages) as part of NORM's probabilistic feedback suppression technique. For example, the maximum NACK delay time is backoffFactor*GRTT. Thus a large backoffFactor value introduces latency into the NORM repair process. However, a small backoffFactor value causes feedback suppression to be less effective and increases the risk of feedback implosion for large receiver group sizes.
The default setting of 4.0 provides reasonable feedback suppression for moderate to large group sizes when multicast feedback is possible. The NORM specification recommends a backoffFactor value of 6.0 when unicast feedback is used. However, for demanding applications (with respect to repair latency) when group sizes are modest, a small (even 0.0) backoffFactor value can be specified to reduce the latency of reliable data delivery.
4.4.16.3. Return Values
This function has no return values.
4.4.17. NormSetGroupSize()
4.4.17.1. Synopsis
#include <normApi.h>
 
 void NormSetGroupSize(NormSessionHandle sessionHandle,
-                      unsigned int      groupSize);
4.4.17.2. Description
This function sets the sender's estimate of receiver group size for the given sessionHandle. The sender advertises its groupSize setting to the receiver group in NORM protocol message headers that, in turn, use this information to shape the distribution curve of their random timeouts for the timer-based, probabilistic feedback suppression technique used in the NORM protocol. Note that the groupSize estimate does not have to be very accurate and values within an order of magnitude of the actual group size tend to produce acceptable performance.
The default groupSize setting in NORM is 1,000 and thus can work well for a wide range of actual receiver group sizes. The penalty of an overly large estimate is statistically a little more latency in reliable data delivery with respect to the round trip time and some potential for excess feedback. A substantial underestimation of groupSize increases the risk of feedback implosion. Currently, the NORM implementation does not attempt to automatically measure groupSize from receiver feedback. Applications could add their own mechanism for this (perhaps keeping explicit track of group membership), or it is possible that future versions of the NRL NORM implementation may have some provision for automatic groupSize estimation by the sender based on receiver feedback messages.
4.4.17.3. Return Values
This function has no return values.
4.4.18. NormSetTxRobustFactor()
4.4.18.1. Synopsis
#include <normApi.h>
+                      unsigned int      groupSize);
4.4.17.2. Description
This function sets the sender's estimate of receiver group size for the given sessionHandle. The sender advertises its groupSize setting to the receiver group in NORM protocol message headers that, in turn, use this information to shape the distribution curve of their random timeouts for the timer-based, probabilistic feedback suppression technique used in the NORM protocol. Note that the groupSize estimate does not have to be very accurate and values within an order of magnitude of the actual group size tend to produce acceptable performance.
The default groupSize setting in NORM is 1,000 and thus can work well for a wide range of actual receiver group sizes. The penalty of an overly large estimate is statistically a little more latency in reliable data delivery with respect to the round trip time and some potential for excess feedback. A substantial underestimation of groupSize increases the risk of feedback implosion. Currently, the NORM implementation does not attempt to automatically measure groupSize from receiver feedback. Applications could add their own mechanism for this (perhaps keeping explicit track of group membership), or it is possible that future versions of the NRL NORM implementation may have some provision for automatic groupSize estimation by the sender based on receiver feedback messages.
4.4.17.3. Return Values
This function has no return values.
4.4.18. NormSetTxRobustFactor()
4.4.18.1. Synopsis
#include <normApi.h>
 
 void NormSetTxRobustFactor(NormSessionHandle sessionHandle,
-                           int               txRobustFactor);
4.4.18.2. Description
This routine sets the "robustness factor" used for various NORM sender functions. These functions include the number of repetitions of "robustly-transmitted" NORM sender commands such as NORM_CMD(FLUSH) or similar application-defined commands, and the number of attempts that are made to collect positive acknowledgement from receivers. These commands are distinct from the NORM reliable data transmission process, but play a role in overall NORM protocol operation. The default txRobustFactor value is 20. This relatively large value makes the NORM sender end-of-transmission flushing and positive acknowledgement collection functions somewhat immune from packet loss. However, for some applications, the default value may make the NORM protocol more "chatty" than desired (particularly if flushing is invoked often). In other situations where the network connectivity may be intermittent or extremely lossy, it may be useful to actually increase this value. The default value (20) is expected to provide reasonable operation across a wide range of network conditions and application types. Since this value is not communicated among NORM participants as part of the protocol operation, it is important that applications consistently set this value among all applications participating in a NORM session.
Setting txRobustFactor to a value of -1 makes the redundant transmission of these commands continue indefinitely until completion. For example, with positive acknowledgement collection, the request process will continue indefinitely until all recipients requested acknowledge or the request is canceled by the application. Similarly, flushing commands would be transmitted repeatedly until data transmission is resumed. Typically, setting txRobustFactor to -1 is not recommended.
4.4.18.3. Return Values
This function has no return values.
4.4.19. NormFileEnqueue()
4.4.19.1. Synopsis
#include <normApi.h>
+                           int               txRobustFactor);
4.4.18.2. Description
This routine sets the "robustness factor" used for various NORM sender functions. These functions include the number of repetitions of "robustly-transmitted" NORM sender commands such as NORM_CMD(FLUSH) or similar application-defined commands, and the number of attempts that are made to collect positive acknowledgement from receivers. These commands are distinct from the NORM reliable data transmission process, but play a role in overall NORM protocol operation. The default txRobustFactor value is 20. This relatively large value makes the NORM sender end-of-transmission flushing and positive acknowledgement collection functions somewhat immune from packet loss. However, for some applications, the default value may make the NORM protocol more "chatty" than desired (particularly if flushing is invoked often). In other situations where the network connectivity may be intermittent or extremely lossy, it may be useful to actually increase this value. The default value (20) is expected to provide reasonable operation across a wide range of network conditions and application types. Since this value is not communicated among NORM participants as part of the protocol operation, it is important that applications consistently set this value among all applications participating in a NORM session.
Setting txRobustFactor to a value of -1 makes the redundant transmission of these commands continue indefinitely until completion. For example, with positive acknowledgement collection, the request process will continue indefinitely until all recipients requested acknowledge or the request is canceled by the application. Similarly, flushing commands would be transmitted repeatedly until data transmission is resumed. Typically, setting txRobustFactor to -1 is not recommended.
4.4.18.3. Return Values
This function has no return values.
4.4.19. NormFileEnqueue()
4.4.19.1. Synopsis
#include <normApi.h>
 
 NormObjectHandle NormFileEnqueue(NormSessionHandle      sessionHandle,
                                  const char*            filename,
                                  const char*            infoPtr = NULL,
-                                 unsigned int           infoLen = 0);
4.4.19.2. Description
This function enqueues a file for transmission within the specified NORM sessionHandle. Note that NormStartSender() must have been previously called before files or any transport objects may be enqueued and transmitted. The fileName parameter specifies the path to the file to be transmitted. The NORM protocol engine read and writes directly from/to file system storage for file transport, potentially providing for a very large virtual "repair window" as needed for some applications. While relative paths with respect to the "current working directory" may be used, it is recommended that full paths be used when possible. The optional infoPtr and infoLen parameters are used to associate NORM_INFO content with the sent transport object. The maximum allowed infoLen corresponds to the segmentSize used in the prior call to NormStartSender(). The use and interpretation of the NORM_INFO content is left to the application's discretion. Example usage of NORM_INFO content for NORM_OBJECT_FILE might include file name, creation date, MIME-type or other information which will enable NORM receivers to properly handle the file when reception is complete.
The application is allowed to enqueue multiple transmit objects within in the "transmit cache" bounds (see NormSetTxCacheBounds()) and enqueued objects are transmitted (and repaired as needed) within the limits determined by automated congestion control (see NormSetCongestionControl()) or fixed rate (see NormSetTxRate()) parameters.
4.4.19.3. Return Values
A NormObjectHandle is returned which the application may use in other NORM API calls as needed. This handle can be considered valid until the application explicitly cancels the object's transmission (see NormObjectCancel()) or a NORM_TX_OBJECT_PURGED event is received for the given object. Note the application may use the NormObjectRetain() method if it wishes to refer to the object after the NORM_TX_OBJECT_PURGED notification. In this case, the application, when finished with the object, must use NormObjectRelease() to free any resources used or else a memory leak condition will result. A value of NORM_OBJECT_INVALID is return upon error. Possible failure conditions include the specified session is not operating as a NormSender, insufficient memory resources were available, or the "transmit cache" limits have been reached and all previously enqueued NORM transmit objects are pending transmission. Also the call will fail if the infoLen parameter exceeds the local NormSender segmentSize limit.
4.4.20. NormDataEnqueue()
4.4.20.1. Synopsis
#include <normApi.h>
+                                 unsigned int           infoLen = 0);
4.4.19.2. Description
This function enqueues a file for transmission within the specified NORM sessionHandle. Note that NormStartSender() must have been previously called before files or any transport objects may be enqueued and transmitted. The fileName parameter specifies the path to the file to be transmitted. The NORM protocol engine read and writes directly from/to file system storage for file transport, potentially providing for a very large virtual "repair window" as needed for some applications. While relative paths with respect to the "current working directory" may be used, it is recommended that full paths be used when possible. The optional infoPtr and infoLen parameters are used to associate NORM_INFO content with the sent transport object. The maximum allowed infoLen corresponds to the segmentSize used in the prior call to NormStartSender(). The use and interpretation of the NORM_INFO content is left to the application's discretion. Example usage of NORM_INFO content for NORM_OBJECT_FILE might include file name, creation date, MIME-type or other information which will enable NORM receivers to properly handle the file when reception is complete.
The application is allowed to enqueue multiple transmit objects within in the "transmit cache" bounds (see NormSetTxCacheBounds()) and enqueued objects are transmitted (and repaired as needed) within the limits determined by automated congestion control (see NormSetCongestionControl()) or fixed rate (see NormSetTxRate()) parameters.
4.4.19.3. Return Values
A NormObjectHandle is returned which the application may use in other NORM API calls as needed. This handle can be considered valid until the application explicitly cancels the object's transmission (see NormObjectCancel()) or a NORM_TX_OBJECT_PURGED event is received for the given object. Note the application may use the NormObjectRetain() method if it wishes to refer to the object after the NORM_TX_OBJECT_PURGED notification. In this case, the application, when finished with the object, must use NormObjectRelease() to free any resources used or else a memory leak condition will result. A value of NORM_OBJECT_INVALID is return upon error. Possible failure conditions include the specified session is not operating as a NormSender, insufficient memory resources were available, or the "transmit cache" limits have been reached and all previously enqueued NORM transmit objects are pending transmission. Also the call will fail if the infoLen parameter exceeds the local NormSender segmentSize limit.
4.4.20. NormDataEnqueue()
4.4.20.1. Synopsis
#include <normApi.h>
 
 NormObjectHandle NormDataEnqueue(NormSessionHandle      sessionHandle,
                                  const char*            dataPtr,
                                  unsigned int           dataLen,
                                  const char*            infoPtr = NULL,
-                                 unsigned int           infoLen = 0);
4.4.20.2. Description
This function enqueues a segment of application memory space for transmission within the specified NORM sessionHandle. Note that NormStartSender() MUST have been previously called before files or any transport objects may be enqueued and transmitted. The dataPtr parameter must be a valid pointer to the area of application memory to be transmitted and the dataLen parameter indicates the quantity of data to transmit. The NORM protocol engine read and writes directly from/to application memory space so it is important that the application does not modify (or deallocate) the memory space during the time the NORM protocol engine may access this area. After calling NormDataEnqueue() for a specific application "dataPtr" memory space, the application MUST NOT deallocate (or change the contents of) that memory space until a NORM_TX_OBJECT_PURGED notification is received for the given object or the application itself explicitly cancels the object's transmission (see NormObjectCancel()).
The optional infoPtr and infoLen parameters are used to associate NORM_INFO content with the sent transport object. The maximum allowed infoLen corresponds to the segmentSize used in the prior call to NormStartSender(). The use and interpretation of the NORM_INFO content is left to the application's discretion. Example usage of NORM_INFO content for NORM_OBJECT_DATA might include application-defined data typing or other information which will enable NORM receiver applications to properly interpret the received data when reception is complete. Of course, it is possible that the application may embed such typing information in the object data content itself. This is left to the application's discretion.
The application is allowed to enqueue multiple transmit objects within in the "transmit cache" bounds (see NormSetTxCacheBounds()) and enqueued objects are transmitted (and repaired as needed) within the limits determined by automated congestion control (see NormSetCongestionControl()) or fixed rate (see NormSetTxRate()) parameters.
4.4.20.3. Return Values
A NormObjectHandle is returned which the application may use in other NORM API calls as needed. This handle can be considered valid until the application explicitly cancels the object's transmission (see NormObjectCancel()) or a NORM_TX_OBJECT_PURGED event is received for the given object. Note the application may use the NormObjectRetain() method if it wishes to refer to the object after the NORM_TX_OBJECT_PURGED notification. In this case, the application, when finished with the object, must use NormObjectRelease() to free any resources used or else a memory leak condition will result. A value of NORM_OBJECT_INVALID is return upon error. Possible failure conditions include the specified session is not operating as a NormSender, insufficient memory resources were available, or the "transmit cache" limits have been reached and all previously enqueued NORM transmit objects are pending transmission. Also the call will fail if the infoLen parameter exceeds the local NormSender segmentSize limit.
4.4.21. NormRequeueObject()
4.4.21.1. Synopsis
#include <normApi.h>
+                                 unsigned int           infoLen = 0);
4.4.20.2. Description
This function enqueues a segment of application memory space for transmission within the specified NORM sessionHandle. Note that NormStartSender() MUST have been previously called before files or any transport objects may be enqueued and transmitted. The dataPtr parameter must be a valid pointer to the area of application memory to be transmitted and the dataLen parameter indicates the quantity of data to transmit. The NORM protocol engine read and writes directly from/to application memory space so it is important that the application does not modify (or deallocate) the memory space during the time the NORM protocol engine may access this area. After calling NormDataEnqueue() for a specific application "dataPtr" memory space, the application MUST NOT deallocate (or change the contents of) that memory space until a NORM_TX_OBJECT_PURGED notification is received for the given object or the application itself explicitly cancels the object's transmission (see NormObjectCancel()).
The optional infoPtr and infoLen parameters are used to associate NORM_INFO content with the sent transport object. The maximum allowed infoLen corresponds to the segmentSize used in the prior call to NormStartSender(). The use and interpretation of the NORM_INFO content is left to the application's discretion. Example usage of NORM_INFO content for NORM_OBJECT_DATA might include application-defined data typing or other information which will enable NORM receiver applications to properly interpret the received data when reception is complete. Of course, it is possible that the application may embed such typing information in the object data content itself. This is left to the application's discretion.
The application is allowed to enqueue multiple transmit objects within in the "transmit cache" bounds (see NormSetTxCacheBounds()) and enqueued objects are transmitted (and repaired as needed) within the limits determined by automated congestion control (see NormSetCongestionControl()) or fixed rate (see NormSetTxRate()) parameters.
4.4.20.3. Return Values
A NormObjectHandle is returned which the application may use in other NORM API calls as needed. This handle can be considered valid until the application explicitly cancels the object's transmission (see NormObjectCancel()) or a NORM_TX_OBJECT_PURGED event is received for the given object. Note the application may use the NormObjectRetain() method if it wishes to refer to the object after the NORM_TX_OBJECT_PURGED notification. In this case, the application, when finished with the object, must use NormObjectRelease() to free any resources used or else a memory leak condition will result. A value of NORM_OBJECT_INVALID is return upon error. Possible failure conditions include the specified session is not operating as a NormSender, insufficient memory resources were available, or the "transmit cache" limits have been reached and all previously enqueued NORM transmit objects are pending transmission. Also the call will fail if the infoLen parameter exceeds the local NormSender segmentSize limit.
4.4.21. NormRequeueObject()
4.4.21.1. Synopsis
#include <normApi.h>
 
 boolNormRequeueObject(NormSessionHandle sessionHandle,
-                      NormObjectHandle  objectHandle);
4.4.21.2. Description
This function allows the application to resend (or reset transmission of) a NORM_OBJECT_FILE or NORM_OBJECT_DATA transmit object that was previously enqueued for the indicated sessionHandle. This function is useful for applications sending to silent (non-NACKing) receivers as it enables the receivers to take advantage of multiple retransmissions of objects (including any auto-parity set, see NormSetAutoParity()) to more robustly receive content. The objectHandle parameter must be a valid transmit NormObjectHandle that has not yet been "purged" from the sender's transmit queue. Upon success, the specified object will be fully retransmitted using the same NORM object transport identifier as was used on its initial transmission. This call may be made at any time to restart transmission of a previously-enqueued object, but the NORM_TX_OBJECT_SENT or NORM_TX_FLUSH_COMPLETED notifications can serve as good cues for an appropriate time to resend an object. If multiple objects are re-queued, they will be resent in order of their initial enqueueing.
The transmit cache bounds set by NormSetTxCacheBounds() determine the number of previously-sent objects retained in the sender's transmit queue and that are thus eligible to be requeued for retransmission. An object may be requeued via this call multiple times, but each distinct requeue should be done after an indication such as NORM_TX_OBJECT_SENT or NORM_TX_FLUSH_COMPLETED for the given object. Otherwise, the object will simply be reset from its current transmission point to transmit from the beginning (i.e. restart). Note that the object type NORM_OBJECT_STREAM cannot currently be requeued.
(TBD - should a "numRepeats" parameter be added to this function?)
4.4.21.3. Return Values
A value of true is returned upon success and a value of false is returned upon failure. Possible reasons for failure include an invalid objectHandle was provided (i.e. a non-transmit object or transmit object that has been "purged" from the transmit queue (see NORM_TX_OBJECT_PURGED)) or the provided object was of type NORM_OBJECT_STREAM.
4.4.22. NormStreamOpen()
4.4.22.1. Synopsis
#include <normApi.h>
+                      NormObjectHandle  objectHandle);
4.4.21.2. Description
This function allows the application to resend (or reset transmission of) a NORM_OBJECT_FILE or NORM_OBJECT_DATA transmit object that was previously enqueued for the indicated sessionHandle. This function is useful for applications sending to silent (non-NACKing) receivers as it enables the receivers to take advantage of multiple retransmissions of objects (including any auto-parity set, see NormSetAutoParity()) to more robustly receive content. The objectHandle parameter must be a valid transmit NormObjectHandle that has not yet been "purged" from the sender's transmit queue. Upon success, the specified object will be fully retransmitted using the same NORM object transport identifier as was used on its initial transmission. This call may be made at any time to restart transmission of a previously-enqueued object, but the NORM_TX_OBJECT_SENT or NORM_TX_FLUSH_COMPLETED notifications can serve as good cues for an appropriate time to resend an object. If multiple objects are re-queued, they will be resent in order of their initial enqueueing.
The transmit cache bounds set by NormSetTxCacheBounds() determine the number of previously-sent objects retained in the sender's transmit queue and that are thus eligible to be requeued for retransmission. An object may be requeued via this call multiple times, but each distinct requeue should be done after an indication such as NORM_TX_OBJECT_SENT or NORM_TX_FLUSH_COMPLETED for the given object. Otherwise, the object will simply be reset from its current transmission point to transmit from the beginning (i.e. restart). Note that the object type NORM_OBJECT_STREAM cannot currently be requeued.
(TBD - should a "numRepeats" parameter be added to this function?)
4.4.21.3. Return Values
A value of true is returned upon success and a value of false is returned upon failure. Possible reasons for failure include an invalid objectHandle was provided (i.e. a non-transmit object or transmit object that has been "purged" from the transmit queue (see NORM_TX_OBJECT_PURGED)) or the provided object was of type NORM_OBJECT_STREAM.
4.4.22. NormStreamOpen()
4.4.22.1. Synopsis
#include <normApi.h>
 
 NormObjectHandle NormStreamOpen(NormSessionHandle      sessionHandle,
                                 unsigned int           bufferSize,
                                 const char*            infoPtr = NULL,
-                                unsigned int           infoLen = 0);
4.4.22.2. Description
This function opens a NORM_OBJECT_STREAM sender object and enqueues it for transmission within the indicated sessionHandle. NORM streams provide reliable, in-order delivery of data content written to the stream by the sender application. Note that no data is sent until subsequent calls to NormStreamWrite() are made unless NORM_INFO content is specified for the stream with the infoPtr and infoLen parameters. Example usage of NORM_INFO content for NORM_OBJECT_STREAM might include application-defined data typing or other information which will enable NORM receiver applications to properly interpret the received stream as it is being received. The NORM protocol engine buffers data written to the stream for original transmission and repair transmissions as needed to achieve reliable transfer. The bufferSize parameter controls the size of the stream's "repair window" which limits how far back the sender will "rewind" to satisfy receiver repair requests.
NORM, as a NACK-oriented protocol, currently lacks a mechanism for receivers to explicitly feedback flow control status to the sender unless the sender application specifically leverages NORM's optional positive-acknowledgement (ACK) features. Thus, the bufferSize selection plays an important role in reliable delivery of NORM stream content. Generally, a larger bufferSize value is safer with respect to reliability, but some applications may wish to limit how far the sender rewinds to repair receivers with poor connectivity with respect to the group at large. Such applications may set a smaller bufferSize to avoid the potential for large latency in data delivery (i.e. favor peak delivery latency over full reliability). This may result in breaks in the reliable delivery of stream data to some receivers, but this form of quasi-reliability while limiting latency may be useful for some types of applications (e.g. reliable real-time messaging, video or sensor or media data transport). Note that NORM receivers can quickly, automatically "resync" to the sender after such breaks if the application leverages the application message boundary recovery features of NORM (see NormStreamMarkEom()).
Note that the current implementation of NORM is designed to support only one active stream per session, and that any NORM_OBJECT_DATA or NORM_OBJECT_FILE objects enqueued for transmission will not begin transmission until an active stream is closed. Applications requiring multiple streams or concurrent file/data transfer SHOULD generally instantiate multiple NormSessions as needed.
Note there is no corresponding "open" call for receiver streams. Receiver NORM_OBJECT_STREAMs are automatically opened by the NORM protocol engine and the receiver applications is notified of new streams via the NORM_RX_OBJECT_NEW notification (see NormGetNextEvent()).
4.4.22.3. Return Values
A NormObjectHandle is returned which the application may use in other NORM API calls as needed. This handle can be considered valid until the application explicitly cancels the object's transmission (see NormObjectCancel()) or a NORM_TX_OBJECT_PURGED event is received for the given object. Note the application may use the NormObjectRetain() method if it wishes to refer to the object after the NORM_TX_OBJECT_PURGED notification. In this case, the application, when finished with the object, must use NormObjectRelease() to free any resources used or else a memory leak condition will result. A value of NORM_OBJECT_INVALID is return upon error. Possible failure conditions include the specified session is not operating as a NormSender, insufficient memory resources were available, or the "transmit cache" bounds have been reached and all previously enqueued NORM transmit objects are pending transmission. Also the call will fail if the infoLen parameter exceeds the local NormSender segmentSize limit.
4.4.23. NormStreamClose()
4.4.23.1. Synopsis
#include <normApi.h>
+                                unsigned int           infoLen = 0);
4.4.22.2. Description
This function opens a NORM_OBJECT_STREAM sender object and enqueues it for transmission within the indicated sessionHandle. NORM streams provide reliable, in-order delivery of data content written to the stream by the sender application. Note that no data is sent until subsequent calls to NormStreamWrite() are made unless NORM_INFO content is specified for the stream with the infoPtr and infoLen parameters. Example usage of NORM_INFO content for NORM_OBJECT_STREAM might include application-defined data typing or other information which will enable NORM receiver applications to properly interpret the received stream as it is being received. The NORM protocol engine buffers data written to the stream for original transmission and repair transmissions as needed to achieve reliable transfer. The bufferSize parameter controls the size of the stream's "repair window" which limits how far back the sender will "rewind" to satisfy receiver repair requests.
NORM, as a NACK-oriented protocol, currently lacks a mechanism for receivers to explicitly feedback flow control status to the sender unless the sender application specifically leverages NORM's optional positive-acknowledgement (ACK) features. Thus, the bufferSize selection plays an important role in reliable delivery of NORM stream content. Generally, a larger bufferSize value is safer with respect to reliability, but some applications may wish to limit how far the sender rewinds to repair receivers with poor connectivity with respect to the group at large. Such applications may set a smaller bufferSize to avoid the potential for large latency in data delivery (i.e. favor peak delivery latency over full reliability). This may result in breaks in the reliable delivery of stream data to some receivers, but this form of quasi-reliability while limiting latency may be useful for some types of applications (e.g. reliable real-time messaging, video or sensor or media data transport). Note that NORM receivers can quickly, automatically "resync" to the sender after such breaks if the application leverages the application message boundary recovery features of NORM (see NormStreamMarkEom()).
Note that the current implementation of NORM is designed to support only one active stream per session, and that any NORM_OBJECT_DATA or NORM_OBJECT_FILE objects enqueued for transmission will not begin transmission until an active stream is closed. Applications requiring multiple streams or concurrent file/data transfer SHOULD generally instantiate multiple NormSessions as needed.
Note there is no corresponding "open" call for receiver streams. Receiver NORM_OBJECT_STREAMs are automatically opened by the NORM protocol engine and the receiver applications is notified of new streams via the NORM_RX_OBJECT_NEW notification (see NormGetNextEvent()).
4.4.22.3. Return Values
A NormObjectHandle is returned which the application may use in other NORM API calls as needed. This handle can be considered valid until the application explicitly cancels the object's transmission (see NormObjectCancel()) or a NORM_TX_OBJECT_PURGED event is received for the given object. Note the application may use the NormObjectRetain() method if it wishes to refer to the object after the NORM_TX_OBJECT_PURGED notification. In this case, the application, when finished with the object, must use NormObjectRelease() to free any resources used or else a memory leak condition will result. A value of NORM_OBJECT_INVALID is return upon error. Possible failure conditions include the specified session is not operating as a NormSender, insufficient memory resources were available, or the "transmit cache" bounds have been reached and all previously enqueued NORM transmit objects are pending transmission. Also the call will fail if the infoLen parameter exceeds the local NormSender segmentSize limit.
4.4.23. NormStreamClose()
4.4.23.1. Synopsis
#include <normApi.h>
 
 void NormStreamClose(NormObjectHandle streamHandle,
-                     bool             graceful = false);
4.4.23.2. Description
This function halts transfer of the stream specified by the streamHandle parameter and releases any resources used unless the associated object has been explicitly retained by a call to NormObjectRetain(). No further calls to NormStreamWrite() will be successful for the given streamHandle. The optional graceful parameter, when set to a value of true, may be used by NORM senders to initiate "graceful" shutdown of a transmit stream. In this case, the sender application will be notified that stream has (most likely) completed reliable transfer via the NORM_TX_OBJECT_PURGED notification upon completion of the graceful shutdown process. When the graceful option is set to true, receivers are notified of the stream end via an "stream end" stream control code in NORM_DATA message and will receive a NORM_RX_OBJECT_COMPLETED notification after all received stream content has been read. Otherwise, the stream is immediately terminated, regardless of receiver state. In this case, this function is equivalent to the NormObjectCancel() routine and may be used for sender or receiver streams. So, it is expected this function (NormStreamClose()) will typically be used for transmit streams by NORM senders.
4.4.23.3. Return Values
This function has no return values.
4.4.24. NormStreamWrite()
4.4.24.1. Synopsis
#include <normApi.h>
+                     bool             graceful = false);
4.4.23.2. Description
This function halts transfer of the stream specified by the streamHandle parameter and releases any resources used unless the associated object has been explicitly retained by a call to NormObjectRetain(). No further calls to NormStreamWrite() will be successful for the given streamHandle. The optional graceful parameter, when set to a value of true, may be used by NORM senders to initiate "graceful" shutdown of a transmit stream. In this case, the sender application will be notified that stream has (most likely) completed reliable transfer via the NORM_TX_OBJECT_PURGED notification upon completion of the graceful shutdown process. When the graceful option is set to true, receivers are notified of the stream end via an "stream end" stream control code in NORM_DATA message and will receive a NORM_RX_OBJECT_COMPLETED notification after all received stream content has been read. Otherwise, the stream is immediately terminated, regardless of receiver state. In this case, this function is equivalent to the NormObjectCancel() routine and may be used for sender or receiver streams. So, it is expected this function (NormStreamClose()) will typically be used for transmit streams by NORM senders.
4.4.23.3. Return Values
This function has no return values.
4.4.24. NormStreamWrite()
4.4.24.1. Synopsis
#include <normApi.h>
 
 unsigned int NormStreamWrite(NormObjectHandle streamHandle 
                              const char*      buffer,
-                             unsigned int     numBytes);
4.4.24.2. Description
This function enqueues data for transmission within the NORM stream specified by the streamHandle parameter. The buffer parameter must be a pointer to the data to be enqueued and the numBytes parameter indicates the length of the data content. Note this call does not block and will return immediately. The return value indicates the number of bytes copied from the provided buffer to the internal stream transmission buffers. Calls to this function will be successful unless the stream's transmit buffer space is fully occupied with data pending original or repair transmission if the stream's "push mode" is set to false (default, see NormStreamSetPushEnable() for details). If the stream's "push mode" is set to true, a call to NormStreamWrite() will always result in copying of application data to the stream at the cost of previously enqueued data pending transmission (original or repair) being dropped by the NORM protocol engine. While NORM NACK-based reliability does not provide explicit flow control, there is some degree of implicit flow control in limiting writing new data to the stream against pending repairs. Other flow control strategies are possible using the NormSetWatermark() function.NormSetWatermark() function.
The NormEvent values NORM_TX_QUEUE_EMPTY and NORM_TX_QUEUE_VACANCY are posted with the NormEvent::object field set to a valid sender stream NormObjectHandle to indicate when the stream is ready for writing via this function. Note that the NORM_TX_QUEUE_VACANCY event type is posted only after the stream's transmit buffer has been completely filled. Thus, the application must make a call to NormStreamWrite() that copies less than the requested numBytes value (return value less than numBytes) before additional NORM_TX_QUEUE_VACANCY events are posted for the given streamHandle (i.e., the event type is not re-posted until the application has again filled the available stream transmit buffer space). By cueing off of NORM_TX_QUEUE_EMPTY, the application can write its "freshest" available data to the stream, but by cueing off of NORM_TX_QUEUE_VACANCY, an application can keep the NORM protocol engine busiest, to achieve the maximum possible throughput at high data rates.
4.4.24.3. Return Values
This function returns the number of bytes of data successfully enqueued for NORM stream transmission. If the underlying send stream buffer is full, this function may return zero or a value less than the requested numBytes.
4.4.25. NormStreamFlush()
4.4.25.1. Synopsis
#include <normApi.h>
+                             unsigned int     numBytes);
4.4.24.2. Description
This function enqueues data for transmission within the NORM stream specified by the streamHandle parameter. The buffer parameter must be a pointer to the data to be enqueued and the numBytes parameter indicates the length of the data content. Note this call does not block and will return immediately. The return value indicates the number of bytes copied from the provided buffer to the internal stream transmission buffers. Calls to this function will be successful unless the stream's transmit buffer space is fully occupied with data pending original or repair transmission if the stream's "push mode" is set to false (default, see NormStreamSetPushEnable() for details). If the stream's "push mode" is set to true, a call to NormStreamWrite() will always result in copying of application data to the stream at the cost of previously enqueued data pending transmission (original or repair) being dropped by the NORM protocol engine. While NORM NACK-based reliability does not provide explicit flow control, there is some degree of implicit flow control in limiting writing new data to the stream against pending repairs. Other flow control strategies are possible using the NormSetWatermark() function.NormSetWatermark() function.
The NormEvent values NORM_TX_QUEUE_EMPTY and NORM_TX_QUEUE_VACANCY are posted with the NormEvent::object field set to a valid sender stream NormObjectHandle to indicate when the stream is ready for writing via this function. Note that the NORM_TX_QUEUE_VACANCY event type is posted only after the stream's transmit buffer has been completely filled. Thus, the application must make a call to NormStreamWrite() that copies less than the requested numBytes value (return value less than numBytes) before additional NORM_TX_QUEUE_VACANCY events are posted for the given streamHandle (i.e., the event type is not re-posted until the application has again filled the available stream transmit buffer space). By cueing off of NORM_TX_QUEUE_EMPTY, the application can write its "freshest" available data to the stream, but by cueing off of NORM_TX_QUEUE_VACANCY, an application can keep the NORM protocol engine busiest, to achieve the maximum possible throughput at high data rates.
4.4.24.3. Return Values
This function returns the number of bytes of data successfully enqueued for NORM stream transmission. If the underlying send stream buffer is full, this function may return zero or a value less than the requested numBytes.
4.4.25. NormStreamFlush()
4.4.25.1. Synopsis
#include <normApi.h>
 
 void NormStreamFlush(NormObjectHandle streamHandle,
                      bool             eom = false,
-                     NormFlushMode    flushMode = NORM_FLUSH_PASSIVE);
4.4.25.2. Description
This function causes an immediate "flush" of the transmit stream specified by the streamHandle parameter. Normally, unless NormStreamSetAutoFlush() has been invoked, the NORM protocol engine buffers data written to a stream until it has accumulated a sufficient quantity to generate a NORM_DATA message with a full payload (as designated by the segmentSize parameter of the NormStartSender() call). This results in most efficient operation with respect to protocol overhead. However, for some NORM streams, the application may not wish wait for such accumulation when critical data has been written to a stream. The default stream "flush" operation invoked via NormStreamFlush() for flushMode equal to NORM_FLUSH_PASSIVE causes NORM to immediately transmit all enqueued data for the stream (subject to session transmit rate limits), even if this results in NORM_DATA messages with "small" payloads. If the optional flushMode parameter is set to NORM_FLUSH_ACTIVE, the application can achieve reliable delivery of stream content up to the current write position in an even more proactive fashion. In this case, the sender additionally, actively transmits NORM_CMD(FLUSH) messages after any enqueued stream content has been sent. This immediately prompt receivers for repair requests which reduces latency of reliable delivery, but at a cost of some additional messaging. Note any such "active" flush activity will be terminated upon the next subsequent write to the stream. If flushMode is set to NORM_FLUSH_NONE, this call has no effect other than the optional end-of-message marking described here.
The optional eom parameter, when set to true, allows the sender application to mark an end-of-message indication (see NormStreamMarkEom()) for the stream and initiate flushing in a single function call. The end-of-message indication causes NORM to embed the appropriate message start byte offset in the NORM_DATA message generated following a subsequent write to the stream with the NORM_FLAGS_MSG_START flag. This mechanism provide a means for automatic application message boundary recovery when receivers join or re-sync to a sender mid-stream.
Note that frequent flushing, particularly for NORM_FLUSH_ACTIVE operation, may result in more NORM protocol activity than usual, so care must be taken in application design and deployment when scalability to large group sizes is expected.
4.4.25.3. Return Values
This function has no return values.
4.4.26. NormStreamSetAutoFlush()
4.4.26.1. Synopsis
#include <normApi.h>
+                     NormFlushMode    flushMode = NORM_FLUSH_PASSIVE);
4.4.25.2. Description
This function causes an immediate "flush" of the transmit stream specified by the streamHandle parameter. Normally, unless NormStreamSetAutoFlush() has been invoked, the NORM protocol engine buffers data written to a stream until it has accumulated a sufficient quantity to generate a NORM_DATA message with a full payload (as designated by the segmentSize parameter of the NormStartSender() call). This results in most efficient operation with respect to protocol overhead. However, for some NORM streams, the application may not wish wait for such accumulation when critical data has been written to a stream. The default stream "flush" operation invoked via NormStreamFlush() for flushMode equal to NORM_FLUSH_PASSIVE causes NORM to immediately transmit all enqueued data for the stream (subject to session transmit rate limits), even if this results in NORM_DATA messages with "small" payloads. If the optional flushMode parameter is set to NORM_FLUSH_ACTIVE, the application can achieve reliable delivery of stream content up to the current write position in an even more proactive fashion. In this case, the sender additionally, actively transmits NORM_CMD(FLUSH) messages after any enqueued stream content has been sent. This immediately prompt receivers for repair requests which reduces latency of reliable delivery, but at a cost of some additional messaging. Note any such "active" flush activity will be terminated upon the next subsequent write to the stream. If flushMode is set to NORM_FLUSH_NONE, this call has no effect other than the optional end-of-message marking described here.
The optional eom parameter, when set to true, allows the sender application to mark an end-of-message indication (see NormStreamMarkEom()) for the stream and initiate flushing in a single function call. The end-of-message indication causes NORM to embed the appropriate message start byte offset in the NORM_DATA message generated following a subsequent write to the stream with the NORM_FLAGS_MSG_START flag. This mechanism provide a means for automatic application message boundary recovery when receivers join or re-sync to a sender mid-stream.
Note that frequent flushing, particularly for NORM_FLUSH_ACTIVE operation, may result in more NORM protocol activity than usual, so care must be taken in application design and deployment when scalability to large group sizes is expected.
4.4.25.3. Return Values
This function has no return values.
4.4.26. NormStreamSetAutoFlush()
4.4.26.1. Synopsis
#include <normApi.h>
 
 void NormStreamSetAutoFlush(NormObjectHandle streamHandle
-                            NormFlushMode    flushMode);
4.4.26.2. Description
This function sets "automated flushing" for the NORM transmit stream indicated by the streamHandle parameter. By default, a NORM transmit stream is "flushed" only when explicitly requested by the application (see NormStreamFlush()). However, to simplify programming, the NORM API allows that automated flushing be enabled such that the "flush" operation occurs every time the full requested buffer provided to a NormStreamWrite() call is successfully enqueued. This may be appropriate for messaging applications where the provided buffers corresponds to an application messages requiring immediate, full transmission. This may make the NORM protocol perhaps more "chatty" than its typical "bulk transfer" form of operation, but can provide a useful capability for some applications.
Possible values for the flushMode parameter include NORM_FLUSH_NONE, NORM_FLUSH_PASSIVE, and NORM_FLUSH_ACTIVE. The default setting for a NORM stream is NORM_FLUSH_NONE where no flushing occurs unless explicitly requested via NormStreamFlush(). By setting the automated flushMode to NORM_FLUSH_PASSIVE, the only action taken is to immediately transmit any data that has been written to the stream, even if "runt" NORM_DATA messages (with payloads less than the NormSender segmentSize parameter) are generated as a result. If NORM_FLUSH_ACTIVE is specified, the automated flushing operation is further augmented with the additional transmission of NORM_CMD(FLUSH) messages to proactively excite the receiver group for repair requests.
4.4.26.3. Return Values
This function has no return values.
4.4.27. NormStreamSetPushEnable()
4.4.27.1. Synopsis
#include <normApi.h>
+                            NormFlushMode    flushMode);
4.4.26.2. Description
This function sets "automated flushing" for the NORM transmit stream indicated by the streamHandle parameter. By default, a NORM transmit stream is "flushed" only when explicitly requested by the application (see NormStreamFlush()). However, to simplify programming, the NORM API allows that automated flushing be enabled such that the "flush" operation occurs every time the full requested buffer provided to a NormStreamWrite() call is successfully enqueued. This may be appropriate for messaging applications where the provided buffers corresponds to an application messages requiring immediate, full transmission. This may make the NORM protocol perhaps more "chatty" than its typical "bulk transfer" form of operation, but can provide a useful capability for some applications.
Possible values for the flushMode parameter include NORM_FLUSH_NONE, NORM_FLUSH_PASSIVE, and NORM_FLUSH_ACTIVE. The default setting for a NORM stream is NORM_FLUSH_NONE where no flushing occurs unless explicitly requested via NormStreamFlush(). By setting the automated flushMode to NORM_FLUSH_PASSIVE, the only action taken is to immediately transmit any data that has been written to the stream, even if "runt" NORM_DATA messages (with payloads less than the NormSender segmentSize parameter) are generated as a result. If NORM_FLUSH_ACTIVE is specified, the automated flushing operation is further augmented with the additional transmission of NORM_CMD(FLUSH) messages to proactively excite the receiver group for repair requests.
4.4.26.3. Return Values
This function has no return values.
4.4.27. NormStreamSetPushEnable()
4.4.27.1. Synopsis
#include <normApi.h>
 
 void NormStreamSetPushEnable(NormObjectHandle streamHandle,
-                             bool             pushEnable);
4.4.27.2. Description
This function controls how the NORM API behaves when the application attempts to enqueue new stream data for transmission when the associated stream's transmit buffer is fully occupied with data pending original or repair transmission. By default (pushEnable = false), a call to NormStreamWrite() will return a zero value under this condition, indicating it was unable to enqueue the new data. However, if pushEnable is set to true for a given streamHandle, the NORM protocol engine will discard the oldest buffered stream data (even if it is pending repair transmission or has never been transmitted) as needed to enqueue the new data. Thus a call to NormStreamWrite() will never fail to copy data. This behavior may be desirable for applications where it is more important to quickly delivery new data than to reliably deliver older data written to a stream. The default behavior for a newly opened stream corresponds to pushEnable equals false. This limits the rate to which an application can write new data to the stream to the current transmission rate and status of the reliable repair process.
4.4.27.3. Return Values
This function has no return values.
4.4.28. NormStreamHasVacancy()
4.4.28.1. Synopsis
#include <normApi.h>
+                             bool             pushEnable);
4.4.27.2. Description
This function controls how the NORM API behaves when the application attempts to enqueue new stream data for transmission when the associated stream's transmit buffer is fully occupied with data pending original or repair transmission. By default (pushEnable = false), a call to NormStreamWrite() will return a zero value under this condition, indicating it was unable to enqueue the new data. However, if pushEnable is set to true for a given streamHandle, the NORM protocol engine will discard the oldest buffered stream data (even if it is pending repair transmission or has never been transmitted) as needed to enqueue the new data. Thus a call to NormStreamWrite() will never fail to copy data. This behavior may be desirable for applications where it is more important to quickly delivery new data than to reliably deliver older data written to a stream. The default behavior for a newly opened stream corresponds to pushEnable equals false. This limits the rate to which an application can write new data to the stream to the current transmission rate and status of the reliable repair process.
4.4.27.3. Return Values
This function has no return values.
4.4.28. NormStreamHasVacancy()
4.4.28.1. Synopsis
#include <normApi.h>
 
-bool NormStreamHasVacancy(NormObjectHandle streamHandle);
4.4.28.2. Description
This function can be used to query whether the transmit stream, specified by the streamHandle parameter, has buffer space available so that the application may successfully make a call to NormStreamWrite(). Normally, a call to NormStreamWrite() itself can be used to make this determination, but this function can be useful when "push mode" has been enabled (see the description of the NormStreamSetPushEnable() function) and the application wants to avoid overwriting data previously written to the stream that has not yet been transmitted. Note that when "push mode" is enabled, a call to NormStreamWrite() will always succeed, overwriting previously-enqueued data if necessary. Normally, this function will return true after a NORM_TX_QUEUE_VACANCY notification has been received for a given NORM stream object.
4.4.28.3. Return Values
This function returns a value of true when there is transmit buffer space to which the application may write and false otherwise.
4.4.29. NormStreamMarkEom()
4.4.29.1. Synopsis
#include <normApi.h>
+bool NormStreamHasVacancy(NormObjectHandle streamHandle);
4.4.28.2. Description
This function can be used to query whether the transmit stream, specified by the streamHandle parameter, has buffer space available so that the application may successfully make a call to NormStreamWrite(). Normally, a call to NormStreamWrite() itself can be used to make this determination, but this function can be useful when "push mode" has been enabled (see the description of the NormStreamSetPushEnable() function) and the application wants to avoid overwriting data previously written to the stream that has not yet been transmitted. Note that when "push mode" is enabled, a call to NormStreamWrite() will always succeed, overwriting previously-enqueued data if necessary. Normally, this function will return true after a NORM_TX_QUEUE_VACANCY notification has been received for a given NORM stream object.
4.4.28.3. Return Values
This function returns a value of true when there is transmit buffer space to which the application may write and false otherwise.
4.4.29. NormStreamMarkEom()
4.4.29.1. Synopsis
#include <normApi.h>
 
-void NormStreamMarkEom(NormObjectHandle streamHandle);
4.4.29.2. Description
This function allows the application to indicate to the NORM protocol engine that the last data successfully written to the stream indicated by streamHandle corresponded to the end of an application-defined message boundary. The end-of-message indication given here will cause the NORM protocol engine to embed the appropriate message start byte offset in the NORM_DATA message generated that contains the data for the subsequent application call to NormStreamWrite(). Use of this end-of-message marking enables NORM receivers to automatically re-sync to application-defined message boundaries when joining (or re-joining) a NORM session already in progress.
4.4.29.3. Return Values
This function has no return values.
4.4.30. NormSetWatermark()
4.4.30.1. Synopsis
#include <normApi.h>
+void NormStreamMarkEom(NormObjectHandle streamHandle);
4.4.29.2. Description
This function allows the application to indicate to the NORM protocol engine that the last data successfully written to the stream indicated by streamHandle corresponded to the end of an application-defined message boundary. The end-of-message indication given here will cause the NORM protocol engine to embed the appropriate message start byte offset in the NORM_DATA message generated that contains the data for the subsequent application call to NormStreamWrite(). Use of this end-of-message marking enables NORM receivers to automatically re-sync to application-defined message boundaries when joining (or re-joining) a NORM session already in progress.
4.4.29.3. Return Values
This function has no return values.
4.4.30. NormSetWatermark()
4.4.30.1. Synopsis
#include <normApi.h>
 
 bool NormSetWatermark(NormSessionHandle sessionHandle,
                       NormObjectHandle  objectHandle, 
-                      bool              overrideFlush = true);
4.4.30.2. Description
This function specifies a "watermark" transmission point at which NORM sender protocol operation should perform a flushing process and/or positive acknowledgment collection for a given sessionHandle. For NORM_OBJECT_FILE and NORM_OBJECT_DATA transmissions, the positive acknowledgement collection will begin when the specified object has been completely transmitted. The objectHandle parameter must be a valid handle to a previously-created sender object (see NormFileEnqueue(), NormDataEnqueue(), or NormStreamOpen()). For NORM_OBJECT_STREAM transmission, the positive acknowledgment collection begins immediately, using the current position (offset of most recent data written) of the sender stream as a reference.
The functions NormAddAckingNode() and NormRemoveAckingNode() are used to manage the list of NormNodeId values corresponding to NORM receivers that are expected to explicitly acknowledge the watermark flushing messages transmitted by the sender. Note that the NormNodeId NORM_NODE_NONE may be included in the list. Inclusion of NORM_NODE_NONE forces the watermark flushing process to proceed through a full NORM_ROBUST_FACTOR number of rounds before completing, prompting any receivers that have not completed reliable reception to the given watermark point to NACK for any repair needs. If NACKs occur, the flushing process is reset and repeated until completing with no NACKs for data through the given watermark transmission point are received. Thus, even without explicit positive acknowledgment, the sender can use this process (by adding NORM_NODE_NONE to the session's list of "acking nodes") for a high level of assurance that the receiver set is "happy" (completed reliable data reception) through the given object (or stream transmission point).
The event NORM_TX_WATERMARK_COMPLETED is posted for the given session when the flushing process or positive acknowledgment collection has completed. The process completes as soon as all listed receivers have responded unless NORM_NODE_NONE is included in the "acking node" list. The sender application may use the function NormGetAckingStatus() to determine the degree of success of the flushing process in general or for individual NormNodeId values.
The flushing is conducted concurrently with ongoing data transmission and does not impede the progress of reliable data transfer. Thus the sender may still enqueue NormObjects for transmission (or write to the existing stream) and the positive acknowledgement collection and flushing procedure will be multiplexed with the ongoing data transmission. However, the sender application may wish to defer from or limit itself in sending more data until a NORM_TX_WATERMARK_COMPLETED event is received for the given session. This provides a form of sender->receiver(s) flow control which does not exist in NORM's default protocol operation. If a subsequent call is made to NormSetWatermark() before the current acknowledgement request has completed, the pending acknowledgment request is canceled and the new one begins.
The optional overrideFlush parameter, when set to true, causes the watermark acknowledgment process that is established with this function call to potentially fully supersede the usual NORM end-of-transmission flushing process that occurs. If overrideFlush is set and the "watermark" transmission point corresponds to the last transmission that will result from data enqueued by the sending application, then the watermark flush completion will terminate the usual flushing process. I.e., if positive acknowledgement of watermark is received from the full "acking node list", then no further flushing is conducted. Thus, the overrideFlush parameter should only be set when the "acking node list" contains a complete list of intended recipients. This is useful for small receiver groups (or unicast operation) to reduce the "chattiness" of NORM's default end-of-transmission flush process. Note that once the watermark flush is completed and further data enqueued and transmitted, the normal default end-of-transmission behavior will be resumed unless another "watermark" is set with overrideFlush enabled. Thus, as long as new watermarks are established by successive use of this API call, this effectively "morphs" NORM into a protocol driven by positive acknowledgement behavior.
4.4.30.3. Return Values
The function returns true upon successful establishment of the watermark point. The function may return false upon failure.
4.4.31. NormCancelWatermark()
4.4.31.1. Synopsis
#include <normApi.h>
+                      bool              overrideFlush = true);
4.4.30.2. Description
This function specifies a "watermark" transmission point at which NORM sender protocol operation should perform a flushing process and/or positive acknowledgment collection for a given sessionHandle. For NORM_OBJECT_FILE and NORM_OBJECT_DATA transmissions, the positive acknowledgement collection will begin when the specified object has been completely transmitted. The objectHandle parameter must be a valid handle to a previously-created sender object (see NormFileEnqueue(), NormDataEnqueue(), or NormStreamOpen()). For NORM_OBJECT_STREAM transmission, the positive acknowledgment collection begins immediately, using the current position (offset of most recent data written) of the sender stream as a reference.
The functions NormAddAckingNode() and NormRemoveAckingNode() are used to manage the list of NormNodeId values corresponding to NORM receivers that are expected to explicitly acknowledge the watermark flushing messages transmitted by the sender. Note that the NormNodeId NORM_NODE_NONE may be included in the list. Inclusion of NORM_NODE_NONE forces the watermark flushing process to proceed through a full NORM_ROBUST_FACTOR number of rounds before completing, prompting any receivers that have not completed reliable reception to the given watermark point to NACK for any repair needs. If NACKs occur, the flushing process is reset and repeated until completing with no NACKs for data through the given watermark transmission point are received. Thus, even without explicit positive acknowledgment, the sender can use this process (by adding NORM_NODE_NONE to the session's list of "acking nodes") for a high level of assurance that the receiver set is "happy" (completed reliable data reception) through the given object (or stream transmission point).
The event NORM_TX_WATERMARK_COMPLETED is posted for the given session when the flushing process or positive acknowledgment collection has completed. The process completes as soon as all listed receivers have responded unless NORM_NODE_NONE is included in the "acking node" list. The sender application may use the function NormGetAckingStatus() to determine the degree of success of the flushing process in general or for individual NormNodeId values.
The flushing is conducted concurrently with ongoing data transmission and does not impede the progress of reliable data transfer. Thus the sender may still enqueue NormObjects for transmission (or write to the existing stream) and the positive acknowledgement collection and flushing procedure will be multiplexed with the ongoing data transmission. However, the sender application may wish to defer from or limit itself in sending more data until a NORM_TX_WATERMARK_COMPLETED event is received for the given session. This provides a form of sender->receiver(s) flow control which does not exist in NORM's default protocol operation. If a subsequent call is made to NormSetWatermark() before the current acknowledgement request has completed, the pending acknowledgment request is canceled and the new one begins.
The optional overrideFlush parameter, when set to true, causes the watermark acknowledgment process that is established with this function call to potentially fully supersede the usual NORM end-of-transmission flushing process that occurs. If overrideFlush is set and the "watermark" transmission point corresponds to the last transmission that will result from data enqueued by the sending application, then the watermark flush completion will terminate the usual flushing process. I.e., if positive acknowledgement of watermark is received from the full "acking node list", then no further flushing is conducted. Thus, the overrideFlush parameter should only be set when the "acking node list" contains a complete list of intended recipients. This is useful for small receiver groups (or unicast operation) to reduce the "chattiness" of NORM's default end-of-transmission flush process. Note that once the watermark flush is completed and further data enqueued and transmitted, the normal default end-of-transmission behavior will be resumed unless another "watermark" is set with overrideFlush enabled. Thus, as long as new watermarks are established by successive use of this API call, this effectively "morphs" NORM into a protocol driven by positive acknowledgement behavior.
4.4.30.3. Return Values
The function returns true upon successful establishment of the watermark point. The function may return false upon failure.
4.4.31. NormCancelWatermark()
4.4.31.1. Synopsis
#include <normApi.h>
 
-bool NormCancelWatermark(NormSessionHandle sessionHandle);
4.4.31.2. Description
This function cancels any "watermark" acknowledgement request that was previously set via the NormSetWatermark() function for the given sessionHandle. The status of any NORM receivers that may have acknowledged prior to cancellation can be queried using the NormGetAckingStatus() function even after NormCancelWatermark() is called. Typically, applications should wait until a event has been posted, but in some special cases it may be useful to terminate the acknowledgement collection process early.
4.4.31.3. Return Values
The function has no return values.
4.4.32. NormAddAckingNode()
4.4.32.1. Synopsis
#include <normApi.h>
+bool NormCancelWatermark(NormSessionHandle sessionHandle);
4.4.31.2. Description
This function cancels any "watermark" acknowledgement request that was previously set via the NormSetWatermark() function for the given sessionHandle. The status of any NORM receivers that may have acknowledged prior to cancellation can be queried using the NormGetAckingStatus() function even after NormCancelWatermark() is called. Typically, applications should wait until a event has been posted, but in some special cases it may be useful to terminate the acknowledgement collection process early.
4.4.31.3. Return Values
The function has no return values.
4.4.32. NormAddAckingNode()
4.4.32.1. Synopsis
#include <normApi.h>
 
 bool NormAddAckingNode(NormSessionHandle sessionHandle,
-                       NormNodeId        nodeId);
4.4.32.2. Description
When this function is called, the specified nodeId is added to the list of NormNodeId values (i.e., the "acking node" list) used when NORM sender operation performs positive acknowledgement (ACK) collection for the specified sessionHandle. The optional NORM positive acknowledgement collection occurs when a specified transmission point (see NormSetWatermark()) is reached or for specialized protocol actions such as positively-acknowledged application-defined commands.
Additionally the special value of nodeId equal to NORM_NODE_NONE may be set to force the watermark flushing process through a full NORM_ROBUST_FACTOR number of rounds regardless of actual acking nodes. Otherwise the flushing process is terminated when all of the nodes in the acking node list have responded. Setting a "watermark" and forcing a full flush process with the special NORM_NODE_NONE value of nodeId enables the resultant NORM_TX_WATERMARK_COMPLETED notification to be a indicator with high (but not absolute) assurance that the receiver set has completed reliable reception of content up through the "watermark" transmission point. This provides a form of scalable reliable multicast "flow control" for NACK-based operation without requiring explicit positive acknowledgement from all group members. Note that the use of the NORM_NODE_NONE value may be mixed with other nodeId for a mix of positive acknowledgement collection from some nodes and a measure of assurance for the group at large.
4.4.32.3. Return Values
The function returns true upon success and false upon failure. The only failure condition is that insufficient memory resources were available. If a specific nodeId is added more than once, this has no effect.
4.4.33. NormRemoveAckingNode()
4.4.33.1. Synopsis
#include <normApi.h>
+                       NormNodeId        nodeId);
4.4.32.2. Description
When this function is called, the specified nodeId is added to the list of NormNodeId values (i.e., the "acking node" list) used when NORM sender operation performs positive acknowledgement (ACK) collection for the specified sessionHandle. The optional NORM positive acknowledgement collection occurs when a specified transmission point (see NormSetWatermark()) is reached or for specialized protocol actions such as positively-acknowledged application-defined commands.
Additionally the special value of nodeId equal to NORM_NODE_NONE may be set to force the watermark flushing process through a full NORM_ROBUST_FACTOR number of rounds regardless of actual acking nodes. Otherwise the flushing process is terminated when all of the nodes in the acking node list have responded. Setting a "watermark" and forcing a full flush process with the special NORM_NODE_NONE value of nodeId enables the resultant NORM_TX_WATERMARK_COMPLETED notification to be a indicator with high (but not absolute) assurance that the receiver set has completed reliable reception of content up through the "watermark" transmission point. This provides a form of scalable reliable multicast "flow control" for NACK-based operation without requiring explicit positive acknowledgement from all group members. Note that the use of the NORM_NODE_NONE value may be mixed with other nodeId for a mix of positive acknowledgement collection from some nodes and a measure of assurance for the group at large.
4.4.32.3. Return Values
The function returns true upon success and false upon failure. The only failure condition is that insufficient memory resources were available. If a specific nodeId is added more than once, this has no effect.
4.4.33. NormRemoveAckingNode()
4.4.33.1. Synopsis
#include <normApi.h>
 
 void NormRemoveAckingNode(NormSessionHandle sessionHandle,
-                          NormNodeId        nodeId);
4.4.33.2. Description
This function deletes the specified nodeId from the list of NormNodeId values used when NORM sender operation performs positive acknowledgement (ACK) collection for the specified sessionHandle. Note that if the special nodeId value "NORM_NODE_NONE" has been added to the list, it too must be explicitly removed to change the watermark flushing behavior if desired.
4.4.33.3. Return Values
The function has no return values.
4.4.34. NormGetNextAckingNode()
4.4.34.1. Synopsis
#include <normApi.h>
+                          NormNodeId        nodeId);
4.4.33.2. Description
This function deletes the specified nodeId from the list of NormNodeId values used when NORM sender operation performs positive acknowledgement (ACK) collection for the specified sessionHandle. Note that if the special nodeId value "NORM_NODE_NONE" has been added to the list, it too must be explicitly removed to change the watermark flushing behavior if desired.
4.4.33.3. Return Values
The function has no return values.
4.4.34. NormGetNextAckingNode()
4.4.34.1. Synopsis
#include <normApi.h>
 
-NormNodeId NormGetNextAckingNode(NormSessionHandle session, bool reset = false);
4.4.34.2. Description
This function iteratively retrieves the NormNodeId values in the "acking node" list maintained by a NORM sender (see NormAddAckingNode()) for the given sessionHandle. If the optional reset parameter is set to a value of true, the first NormNodeId value in the list is returned and subsequent calls to NormGetNextAckingNode()with the reset parameter set to its default false value will iteratively return the remaining NormNodeId values contained in the list. A value of NORM_NODE_NONE is returned when the end of the list is reached.
The "acking node" list is populated with application calls to NormAddAckingNode() or auto-populated if that optional behavior is set for a NormSession. Note that this API does not enable the programmer to check if the NORM_NODE_NONE value itself is contained in the list. The programmer should keep track of that by other means.
The following code example illustrates how to use this call to iterate through the set of stored NormNodeId values and get the current "acking status" for each:
NormNodeId nextNodeId = NormGetNextAckingNode(session, true);
+NormNodeId NormGetNextAckingNode(NormSessionHandle session, bool reset = false);
4.4.34.2. Description
This function iteratively retrieves the NormNodeId values in the "acking node" list maintained by a NORM sender (see NormAddAckingNode()) for the given sessionHandle. If the optional reset parameter is set to a value of true, the first NormNodeId value in the list is returned and subsequent calls to NormGetNextAckingNode()with the reset parameter set to its default false value will iteratively return the remaining NormNodeId values contained in the list. A value of NORM_NODE_NONE is returned when the end of the list is reached.
The "acking node" list is populated with application calls to NormAddAckingNode() or auto-populated if that optional behavior is set for a NormSession. Note that this API does not enable the programmer to check if the NORM_NODE_NONE value itself is contained in the list. The programmer should keep track of that by other means.
The following code example illustrates how to use this call to iterate through the set of stored NormNodeId values and get the current "acking status" for each:
NormNodeId nextNodeId = NormGetNextAckingNode(session, true);
 while(NORM_NODE_NONE != nextNodeId)
 {
     NormAckingStatus ackingStatus = NormGetAckingStatus(session, nextNodeId);
     printf("ACKing node id = %lu acking status = %d\n", nextNodeId, (int)ackingStatus);
-}
As noted below, a good time to check the acking status of the receiver set is after a NORM_TX_WATERMARK_COMPLETED notification has occurred.
4.4.34.3. Return Values
The function iteratively returns NormNodeId values from the given session's local sender "acking node" list. A value of NORM_NODE_NONE is returned when the end of the list is reached.
4.4.35. NormGetAckingStatus()
4.4.35.1. Synopsis
#include <normApi.h>
+}
As noted below, a good time to check the acking status of the receiver set is after a NORM_TX_WATERMARK_COMPLETED notification has occurred.
4.4.34.3. Return Values
The function iteratively returns NormNodeId values from the given session's local sender "acking node" list. A value of NORM_NODE_NONE is returned when the end of the list is reached.
4.4.35. NormGetAckingStatus()
4.4.35.1. Synopsis
#include <normApi.h>
 
 NormAckingStatus NormGetAckingStatus(NormSessionHandle sessionHandle,
-                                     NormNodeId        nodeId = NORM_NODE_ANY);
4.4.35.2. Description
This function queries the status of the watermark flushing process and/or positive acknowledgment collection initiated by a prior call to NormSetWatermark() for the given sessionHandle. In general, it is expected that applications will invoke this function after the corresponding NORM_TX_WATERMARK_COMPLETED event has been posted. Setting the default parameter value nodeId = NORM_NODE_ANY returns a "status" indication for the overall process. Also, individual nodeId values may be queried using the NormNodeId values of receivers that were included in previous calls to NormAddAckingNode() to populate the sender session's acking node list.
If the flushing/acknowledgment process is being used for application flow control, the sender application may wish to reset the watermark and flushing process (using NormSetWatermark()) if the response indicates that some nodes have failed to respond. However, note that the flushing/acknowledgment process itself does elicit NACKs from receivers as needed and is interrupted and reset by any repair response that occurs. Thus, even by the time the flushing process has completed (and NORM_TX_WATERMARK_COMPLETED is posted) once, this is an indication that the NORM protocol has made a valiant attempt to deliver the content. Resetting the watermark process can increase robustness, but it may be in vain to repeat this process multiple times when likely network connectivity has been lost or expected receivers have failed (dropped out, shut down, etc).
4.4.35.3. Return Values
Possible return values include:
NORM_ACK_INVALID
The given sessionHandle is invalid or the given nodeId is not in the sender's acking list.
NORM_ACK_FAILURE
The positive acknowledgement collection process did not receive acknowledgment from every listed receiver (nodeId = NORM_NODE_ANY) or the identified nodeId did not respond.
NORM_ACK_PENDING
The flushing process at large has not yet completed (nodeId = NORM_NODE_ANY) or the given individual nodeId is still being queried for response.
NORM_ACK_SUCCESS
All receivers (nodeId = NORM_NODE_ANY) responded with positive acknowledgement or the given specific nodeId did acknowledge.
4.4.36. NormSendCommand()
4.4.36.1. Synopsis
#include <normApi.h>
+                                     NormNodeId        nodeId = NORM_NODE_ANY);
4.4.35.2. Description
This function queries the status of the watermark flushing process and/or positive acknowledgment collection initiated by a prior call to NormSetWatermark() for the given sessionHandle. In general, it is expected that applications will invoke this function after the corresponding NORM_TX_WATERMARK_COMPLETED event has been posted. Setting the default parameter value nodeId = NORM_NODE_ANY returns a "status" indication for the overall process. Also, individual nodeId values may be queried using the NormNodeId values of receivers that were included in previous calls to NormAddAckingNode() to populate the sender session's acking node list.
If the flushing/acknowledgment process is being used for application flow control, the sender application may wish to reset the watermark and flushing process (using NormSetWatermark()) if the response indicates that some nodes have failed to respond. However, note that the flushing/acknowledgment process itself does elicit NACKs from receivers as needed and is interrupted and reset by any repair response that occurs. Thus, even by the time the flushing process has completed (and NORM_TX_WATERMARK_COMPLETED is posted) once, this is an indication that the NORM protocol has made a valiant attempt to deliver the content. Resetting the watermark process can increase robustness, but it may be in vain to repeat this process multiple times when likely network connectivity has been lost or expected receivers have failed (dropped out, shut down, etc).
4.4.35.3. Return Values
Possible return values include:
NORM_ACK_INVALID
The given sessionHandle is invalid or the given nodeId is not in the sender's acking list.
NORM_ACK_FAILURE
The positive acknowledgement collection process did not receive acknowledgment from every listed receiver (nodeId = NORM_NODE_ANY) or the identified nodeId did not respond.
NORM_ACK_PENDING
The flushing process at large has not yet completed (nodeId = NORM_NODE_ANY) or the given individual nodeId is still being queried for response.
NORM_ACK_SUCCESS
All receivers (nodeId = NORM_NODE_ANY) responded with positive acknowledgement or the given specific nodeId did acknowledge.
4.4.36. NormSendCommand()
4.4.36.1. Synopsis
#include <normApi.h>
 
 bool NormSendCommand(NormSessionHandle session,
                      const char*       cmdBuffer,
                      unsigned int      cmdLength,
-                     bool              robust = false); 
4.4.36.2. Description
This function enqueues a NORM application-defined command for transmission. The cmdBuffer parameter points to a buffer containing the application-defined command content that will be contained in the NORM_CMD(APPLICATION) message payload. The cmdLength indicates the length of this content (in bytes) and MUST be less than or equal to the segmentLength value for the given session (see NormStartSender()). The NORM command transmission will be multiplexed with any NORM data transmission. The command is NOT delivered reliably, but can be optionally transmitted with repetition (once per GRTT) according to the NORM transmit robust factor value (see NormSetTxRobustFactor()) for the given session if the robust parameter is set to true. The command transmission is subject to any congestion control or set rate limits for the NORM session. Once the command has been transmitted (with repetition if robust is set to true), a NORM_TX_CMD_SENT notification is issued. An application can only enqueue a single command at a time (i.e. the NORM_TX_CMD_SENT notification must occur before another command can be sent). The NormCancelCommand() call is available to terminate command transmission if needed. Note that if a rapid succession of commands are sent it is possible that the commands may be delivered to the receivers out-of-order. Also, when repetition is requested (i.e., if robust is set to true) the receiver may receive duplicate copies of the same command. It is up to the application to provide any needed mechanism for detecting and/or filtering duplicate command reception.
The application-defined command feature allows NORM applications to provide some out-of-band (with respect to reliable data delivery) signaling to support session management or other functions. The reception of these "atomic" commands is relatively stateless (as compared to reliable data delivery) and thus it is possible for many senders within a group to send commands without extreme resource burden on receivers (i.e. other participants). Again, this "light-weight" signaling mechanism may be used to provide ancillary communication for the group. In the future, an additional API mechanism will be provided to support application-defined positive acknowledgement requests that could conceivably be used to help guarantee command delivery if desired.
4.4.36.3. Return Values
The function returns true upon success. The function may fail, returning false, if the session is not set for sender operation (see NormStartSender()), the cmdLength exceeds the configured session segmentLength, or a previously-enqueued command has not yet been sent.
4.4.37. NormCancelCommand()
4.4.37.1. Synopsis
#include <normApi.h>
+                     bool              robust = false); 
4.4.36.2. Description
This function enqueues a NORM application-defined command for transmission. The cmdBuffer parameter points to a buffer containing the application-defined command content that will be contained in the NORM_CMD(APPLICATION) message payload. The cmdLength indicates the length of this content (in bytes) and MUST be less than or equal to the segmentLength value for the given session (see NormStartSender()). The NORM command transmission will be multiplexed with any NORM data transmission. The command is NOT delivered reliably, but can be optionally transmitted with repetition (once per GRTT) according to the NORM transmit robust factor value (see NormSetTxRobustFactor()) for the given session if the robust parameter is set to true. The command transmission is subject to any congestion control or set rate limits for the NORM session. Once the command has been transmitted (with repetition if robust is set to true), a NORM_TX_CMD_SENT notification is issued. An application can only enqueue a single command at a time (i.e. the NORM_TX_CMD_SENT notification must occur before another command can be sent). The NormCancelCommand() call is available to terminate command transmission if needed. Note that if a rapid succession of commands are sent it is possible that the commands may be delivered to the receivers out-of-order. Also, when repetition is requested (i.e., if robust is set to true) the receiver may receive duplicate copies of the same command. It is up to the application to provide any needed mechanism for detecting and/or filtering duplicate command reception.
The application-defined command feature allows NORM applications to provide some out-of-band (with respect to reliable data delivery) signaling to support session management or other functions. The reception of these "atomic" commands is relatively stateless (as compared to reliable data delivery) and thus it is possible for many senders within a group to send commands without extreme resource burden on receivers (i.e. other participants). Again, this "light-weight" signaling mechanism may be used to provide ancillary communication for the group. In the future, an additional API mechanism will be provided to support application-defined positive acknowledgement requests that could conceivably be used to help guarantee command delivery if desired.
4.4.36.3. Return Values
The function returns true upon success. The function may fail, returning false, if the session is not set for sender operation (see NormStartSender()), the cmdLength exceeds the configured session segmentLength, or a previously-enqueued command has not yet been sent.
4.4.37. NormCancelCommand()
4.4.37.1. Synopsis
#include <normApi.h>
 
-void NormCancelCommand(NormSessionHandle session);
4.4.37.2. Description
This function terminates any pending NORM_CMD(APPLICATION) transmission that was previously initiated with the NormSendCommand() call. Due to the asynchrony of the NORM protocol engine thread and the application, it is possible that the command may have been already sent but the NormCancelCommand() call will ensure a NORM_TX_CMD_SENT notification is not issued for that prior command.
The application-defined command feature allows NORM applications to provide some out-of-band (with respect to reliable data delivery) signaling to support session management or other functions. The reception of these "atomic" commands is relatively stateless (as compared to reliable data delivery) and thus it is possible for many senders within a group to send commands without extreme resource burden on receivers (i.e. other participants). Again, this "light-weight" signaling mechanism may be used to provide ancillary communication for the group. In the future, an additional API mechanism will be provided to support application-defined positive acknowledgement requests that could conceivably be used to help guarantee command delivery if desired.
4.4.37.3. Return Values
The function has not return value.
4.5. NORM Receiver Functions
4.5.1. NormStartReceiver()
4.5.1.1. Synopsis
#include <normApi.h>
+void NormCancelCommand(NormSessionHandle session);
4.4.37.2. Description
This function terminates any pending NORM_CMD(APPLICATION) transmission that was previously initiated with the NormSendCommand() call. Due to the asynchrony of the NORM protocol engine thread and the application, it is possible that the command may have been already sent but the NormCancelCommand() call will ensure a NORM_TX_CMD_SENT notification is not issued for that prior command.
The application-defined command feature allows NORM applications to provide some out-of-band (with respect to reliable data delivery) signaling to support session management or other functions. The reception of these "atomic" commands is relatively stateless (as compared to reliable data delivery) and thus it is possible for many senders within a group to send commands without extreme resource burden on receivers (i.e. other participants). Again, this "light-weight" signaling mechanism may be used to provide ancillary communication for the group. In the future, an additional API mechanism will be provided to support application-defined positive acknowledgement requests that could conceivably be used to help guarantee command delivery if desired.
4.4.37.3. Return Values
The function has not return value.
4.5. NORM Receiver Functions
4.5.1. NormStartReceiver()
4.5.1.1. Synopsis
#include <normApi.h>
 
 bool NormStartReceiver(NormSessionHandle sessionHandle,
-                       unsigned long     bufferSpace);
4.5.1.2. Description
This function initiates the application's participation as a receiver within the NormSession identified by the sessionHandle parameter. The NORM protocol engine will begin providing the application with receiver-related NormEvent notifications, and, unless NormSetSilentReceiver(true) is invoked, respond to senders with appropriate protocol messages. The bufferSpace parameter is used to set a limit on the amount of bufferSpace allocated by the receiver per active NormSender within the session. The appropriate bufferSpace to use is a function of expected network delay*bandwidth product and packet loss characteristics. A discussion of trade-offs associated with NORM transmit and receiver buffer space selection is provided later in this document. An insufficient bufferSpace allocation will result in potentially inefficient protocol operation, even though reliable operation may be maintained. In some cases of a large delay*bandwidth product and/or severe packet loss, a small bufferSpace allocation (coupled with the lack of explicit flow control in NORM) may result in the receiver "re-syncing" to the sender, resulting in "outages" in the reliable transmissions from a sender (this is analogous to a TCP connection timeout failure).
4.5.1.3. Return Values
A value of true is returned upon success and false upon failure. The reasons failure may occur include limited system resources or that the network sockets required for session communication failed to open or properly configure.
4.5.2. NormStopReceiver()
4.5.2.1. Synopsis
#include <normApi.h>
+                       unsigned long     bufferSpace);
4.5.1.2. Description
This function initiates the application's participation as a receiver within the NormSession identified by the sessionHandle parameter. The NORM protocol engine will begin providing the application with receiver-related NormEvent notifications, and, unless NormSetSilentReceiver(true) is invoked, respond to senders with appropriate protocol messages. The bufferSpace parameter is used to set a limit on the amount of bufferSpace allocated by the receiver per active NormSender within the session. The appropriate bufferSpace to use is a function of expected network delay*bandwidth product and packet loss characteristics. A discussion of trade-offs associated with NORM transmit and receiver buffer space selection is provided later in this document. An insufficient bufferSpace allocation will result in potentially inefficient protocol operation, even though reliable operation may be maintained. In some cases of a large delay*bandwidth product and/or severe packet loss, a small bufferSpace allocation (coupled with the lack of explicit flow control in NORM) may result in the receiver "re-syncing" to the sender, resulting in "outages" in the reliable transmissions from a sender (this is analogous to a TCP connection timeout failure).
4.5.1.3. Return Values
A value of true is returned upon success and false upon failure. The reasons failure may occur include limited system resources or that the network sockets required for session communication failed to open or properly configure.
4.5.2. NormStopReceiver()
4.5.2.1. Synopsis
#include <normApi.h>
 
 void NormStopReceiver(NormSessionHandle sessionHandle,
-                      unsigned int      gracePeriod = 0);
4.5.2.2. Description
This function ends the application's participation as a receiver in the NormSession specified by the session parameter. By default, all receiver-related protocol activity is immediately halted and all receiver-related resources are freed (except for those which have been specifically retained (see NormNodeRetain() and NormObjectRetain()). However, and optional gracePeriod parameter is provided to allow the receiver an opportunity to inform the group of its intention. This is applicable when the local receiving NormNode has been designated as an active congestion control representative (i.e. current limiting receiver (CLR) or potential limiting receiver (PLR)). In this case, a non-zero gracePeriod value provides an opportunity for the receiver to respond to the applicable sender(s) so the sender will not expect further congestion control feedback from this receiver. The gracePeriod integer value is used as a multiplier with the largest sender GRTT to determine the actual time period for which the receiver will linger in the group to provide such feedback (i.e. "graceTime" = (gracePeriod * GRTT)). During this time, the receiver will not generate any requests for repair or other protocol actions aside from response to applicable congestion control probes. When the receiver is removed from the current list of receivers in the sender congestion control probe messages (or the gracePeriod expires, whichever comes first), the NORM protocol engine will post a NORM_LOCAL_RECEIVER_CLOSED event for the applicable session, and related resources are then freed.
4.5.2.3. Return Values
This function has no return values.
4.5.3. NormSetRxCacheLimit()
4.5.3.1. Synopsis
#include <normApi.h>
+                      unsigned int      gracePeriod = 0);
4.5.2.2. Description
This function ends the application's participation as a receiver in the NormSession specified by the session parameter. By default, all receiver-related protocol activity is immediately halted and all receiver-related resources are freed (except for those which have been specifically retained (see NormNodeRetain() and NormObjectRetain()). However, and optional gracePeriod parameter is provided to allow the receiver an opportunity to inform the group of its intention. This is applicable when the local receiving NormNode has been designated as an active congestion control representative (i.e. current limiting receiver (CLR) or potential limiting receiver (PLR)). In this case, a non-zero gracePeriod value provides an opportunity for the receiver to respond to the applicable sender(s) so the sender will not expect further congestion control feedback from this receiver. The gracePeriod integer value is used as a multiplier with the largest sender GRTT to determine the actual time period for which the receiver will linger in the group to provide such feedback (i.e. "graceTime" = (gracePeriod * GRTT)). During this time, the receiver will not generate any requests for repair or other protocol actions aside from response to applicable congestion control probes. When the receiver is removed from the current list of receivers in the sender congestion control probe messages (or the gracePeriod expires, whichever comes first), the NORM protocol engine will post a NORM_LOCAL_RECEIVER_CLOSED event for the applicable session, and related resources are then freed.
4.5.2.3. Return Values
This function has no return values.
4.5.3. NormSetRxCacheLimit()
4.5.3.1. Synopsis
#include <normApi.h>
 
 void NormSetRxCacheLimit(NormSessionHandle sessionHandle,
-                         unsigned short    countMax);
4.5.3.2. Description
This function sets a limit on the number of outstanding (pending) NormObjects for which a receiver will keep state on a per-sender basis. Note that the value countMax sets a limit on the maximum consecutive range of objects that can be pending. The default value (when this function is not called) of countMax is 256. This should be sufficient for most bulk transfer usage, but if small object sizes (e.g. small NORM_OBJECT_DATA messages) are being transferred, it may be useful to raise this limit in cases of high transmission speeds or large <delay*bandwidth, loss> network conditions. If the receiver cache limit is set too small (i.e. for high speed or large <delay*bandwidth> operation), the receiver may not maintain reliable reception or impact session throughput when flow control is enabled (see NormSetFlowControl()). The maximum allowed value of countMax is 16,384.
If this value is changed after NormStartReceiver() has been called, it will only affect newly-detected remote senders, so this should typically be called before NORM receiver operation is initiated.
4.5.3.3. Return Values
This function has no return value.
4.5.4. NormSetRxSocketBuffer()
4.5.4.1. Synopsis
#include <normApi.h>
+                         unsigned short    countMax);
4.5.3.2. Description
This function sets a limit on the number of outstanding (pending) NormObjects for which a receiver will keep state on a per-sender basis. Note that the value countMax sets a limit on the maximum consecutive range of objects that can be pending. The default value (when this function is not called) of countMax is 256. This should be sufficient for most bulk transfer usage, but if small object sizes (e.g. small NORM_OBJECT_DATA messages) are being transferred, it may be useful to raise this limit in cases of high transmission speeds or large <delay*bandwidth, loss> network conditions. If the receiver cache limit is set too small (i.e. for high speed or large <delay*bandwidth> operation), the receiver may not maintain reliable reception or impact session throughput when flow control is enabled (see NormSetFlowControl()). The maximum allowed value of countMax is 16,384.
If this value is changed after NormStartReceiver() has been called, it will only affect newly-detected remote senders, so this should typically be called before NORM receiver operation is initiated.
4.5.3.3. Return Values
This function has no return value.
4.5.4. NormSetRxSocketBuffer()
4.5.4.1. Synopsis
#include <normApi.h>
 
 bool NormSetRxSocketBuffer(NormSessionHandle sessionHandle,
-                           unsigned int      bufferSize);
4.5.4.2. Description
This function allows the application to set an alternative, non-default buffer size for the UDP socket used by the specified NORM sessionHandle for packet reception. This may be necessary for high speed NORM sessions where the UDP receive socket buffer becomes a bottleneck when the NORM protocol engine (which is running as a user-space process) doesn't get to service the receive socket quickly enough resulting in packet loss when the socket buffer overflows. The bufferSize parameter specifies the socket buffer size in bytes. Different operating systems and sometimes system configurations allow different ranges of socket buffer sizes to be set. Note that a call to NormStartReceiver() (or NormStartSender()) must have been previously made for this call to succeed (i.e., the socket must be already open).
4.5.4.3. Return Values
This function returns true upon success and false upon failure. Possible reasons for failure include, 1) the specified session is not valid, 2) that NORM "receiver" (or "sender") operation has not yet been started for the given session, or 3) an invalid bufferSize specification was given.
4.5.5. NormSetSilentReceiver()
4.5.5.1. Synopsis
#include <normApi.h>
+                           unsigned int      bufferSize);
4.5.4.2. Description
This function allows the application to set an alternative, non-default buffer size for the UDP socket used by the specified NORM sessionHandle for packet reception. This may be necessary for high speed NORM sessions where the UDP receive socket buffer becomes a bottleneck when the NORM protocol engine (which is running as a user-space process) doesn't get to service the receive socket quickly enough resulting in packet loss when the socket buffer overflows. The bufferSize parameter specifies the socket buffer size in bytes. Different operating systems and sometimes system configurations allow different ranges of socket buffer sizes to be set. Note that a call to NormStartReceiver() (or NormStartSender()) must have been previously made for this call to succeed (i.e., the socket must be already open).
4.5.4.3. Return Values
This function returns true upon success and false upon failure. Possible reasons for failure include, 1) the specified session is not valid, 2) that NORM "receiver" (or "sender") operation has not yet been started for the given session, or 3) an invalid bufferSize specification was given.
4.5.5. NormSetSilentReceiver()
4.5.5.1. Synopsis
#include <normApi.h>
 
 void NormSetSilentReceiver(NormSessionHandle sessionHandle,
                            bool              silent,
-                           INT32             maxDelay = -1);
4.5.5.2. Description
This function provides the option to configure a NORM receiver application as a "silent receiver". This mode of receiver operation dictates that the host does not generate any protocol messages while operating as a receiver within the specified sessionHandle. Setting the silent parameter to true enables silent receiver operation while setting it to false results in normal protocol operation where feedback is provided as needed for reliability and protocol operation. Silent receivers are dependent upon proactive FEC transmission (see NormSetAutoParity()) or using repair information requested by other non-silent receivers within the group to achieve reliable transfers.
The optional maxDelay parameter is most applicable for reception of the NORM_OBJECT_STREAM type. The default value of maxDelay = -1 corresponds to normal operation where source data segments for incompletely-received FEC coding blocks (or transport objects) are passed to the application only when imposed buffer constraints (either the NORM_OBJECT_STREAM buffer size (see NormStreamOpen()) or the FEC receive buffer limit (see NormStartReceiver()) require. Thus, the default behavior (maxDelay = -1), causes the receiver to buffer received FEC code blocks for as long as possible (within buffer constraints as newer data arrives) before allowing the application to read the data. Hence, the receive latency (delay) can be quite long depending upon buffer size settings, transmission rate, etc. When the maxDelay parameter is set to a non-negative value, the value determines the maximum number of FEC coding blocks (according to a NORM sender's current transmit position) the receiver will cache an incompletely-received FEC block before giving the application the (incomplete) set of received source segments. For example, a value of maxDelay = 0 will provide the receive application with any data from the previous FEC block as soon as a subsequent FEC block is begun reception. However, this provide no protection against the possibility of out-of-order delivery of packets by the network. Therefore, if lower latency operation is desired when using silent receivers, a minimum maxDelay value of 1 is recommended. For NORM_OBJECT_FILE and NORM_OBJECT_DATA, the only impact of a non-negative maxDelay value is that previous transport objects will be immediately aborted when subsequent object begin reception. Thus, it is not usually recommended to apply a non-negative maxDelay value when NORM_OBJECT_STREAM is not being used.
4.5.5.3. Return Values
This function has no return values.
4.5.6. NormSetDefaultUnicastNack()
4.5.6.1. Synopsis
#include <normApi.h>
+                           INT32             maxDelay = -1);
4.5.5.2. Description
This function provides the option to configure a NORM receiver application as a "silent receiver". This mode of receiver operation dictates that the host does not generate any protocol messages while operating as a receiver within the specified sessionHandle. Setting the silent parameter to true enables silent receiver operation while setting it to false results in normal protocol operation where feedback is provided as needed for reliability and protocol operation. Silent receivers are dependent upon proactive FEC transmission (see NormSetAutoParity()) or using repair information requested by other non-silent receivers within the group to achieve reliable transfers.
The optional maxDelay parameter is most applicable for reception of the NORM_OBJECT_STREAM type. The default value of maxDelay = -1 corresponds to normal operation where source data segments for incompletely-received FEC coding blocks (or transport objects) are passed to the application only when imposed buffer constraints (either the NORM_OBJECT_STREAM buffer size (see NormStreamOpen()) or the FEC receive buffer limit (see NormStartReceiver()) require. Thus, the default behavior (maxDelay = -1), causes the receiver to buffer received FEC code blocks for as long as possible (within buffer constraints as newer data arrives) before allowing the application to read the data. Hence, the receive latency (delay) can be quite long depending upon buffer size settings, transmission rate, etc. When the maxDelay parameter is set to a non-negative value, the value determines the maximum number of FEC coding blocks (according to a NORM sender's current transmit position) the receiver will cache an incompletely-received FEC block before giving the application the (incomplete) set of received source segments. For example, a value of maxDelay = 0 will provide the receive application with any data from the previous FEC block as soon as a subsequent FEC block is begun reception. However, this provide no protection against the possibility of out-of-order delivery of packets by the network. Therefore, if lower latency operation is desired when using silent receivers, a minimum maxDelay value of 1 is recommended. For NORM_OBJECT_FILE and NORM_OBJECT_DATA, the only impact of a non-negative maxDelay value is that previous transport objects will be immediately aborted when subsequent object begin reception. Thus, it is not usually recommended to apply a non-negative maxDelay value when NORM_OBJECT_STREAM is not being used.
4.5.5.3. Return Values
This function has no return values.
4.5.6. NormSetDefaultUnicastNack()
4.5.6.1. Synopsis
#include <normApi.h>
 
 void NormSetDefaultUnicastNack(NormSessionHandle sessionHandle,
-                               bool              enable);
4.5.6.2. Description
This function controls the default behavior determining the destination of receiver feedback messages generated while participating in the session. If the enable parameter is true, "unicast NACKing" is enabled for new remote senders while it is disabled for state equal to false. The NACKing behavior for current remote senders is not affected. When "unicast NACKing" is disabled (default), NACK messages are sent to the session address (usually a multicast address) and port, but when "unicast NACKing" is enabled, receiver feedback messages are sent to the unicast address (and port) based on the source address of sender messages received. For unicast NORM sessions, it is recommended that "unicast NACKing" be enabled. Note that receiver feedback messages subject to potential "unicast NACKing" include NACK-messages as well as some ACK messages such as congestion control feedback. Explicitly solicited ACK messages, such as those used to satisfy sender watermark acknowledgement requests (see NormSetWatermark()) are always unicast to the applicable sender. (TBD - provide API option so that all messages are multicast.) The default session-wide behavior for unicast NACKing can be overridden via the NormNodeSetUnicastNack() function for individual remote senders.
4.5.6.3. Return Values
This function has no return values.
4.5.7. NormNodeSetUnicastNack()
4.5.7.1. Synopsis
#include <normApi.h>
+                               bool              enable);
4.5.6.2. Description
This function controls the default behavior determining the destination of receiver feedback messages generated while participating in the session. If the enable parameter is true, "unicast NACKing" is enabled for new remote senders while it is disabled for state equal to false. The NACKing behavior for current remote senders is not affected. When "unicast NACKing" is disabled (default), NACK messages are sent to the session address (usually a multicast address) and port, but when "unicast NACKing" is enabled, receiver feedback messages are sent to the unicast address (and port) based on the source address of sender messages received. For unicast NORM sessions, it is recommended that "unicast NACKing" be enabled. Note that receiver feedback messages subject to potential "unicast NACKing" include NACK-messages as well as some ACK messages such as congestion control feedback. Explicitly solicited ACK messages, such as those used to satisfy sender watermark acknowledgement requests (see NormSetWatermark()) are always unicast to the applicable sender. (TBD - provide API option so that all messages are multicast.) The default session-wide behavior for unicast NACKing can be overridden via the NormNodeSetUnicastNack() function for individual remote senders.
4.5.6.3. Return Values
This function has no return values.
4.5.7. NormNodeSetUnicastNack()
4.5.7.1. Synopsis
#include <normApi.h>
 
 void NormNodeSetUnicastNack(NormNodeHandle senderNode,
-                            bool           enable);
4.5.7.2. Description
This function controls the destination address of receiver feedback messages generated in response to a specific remote NORM sender corresponding to the senderNode parameter. If enable is true, "unicast NACKing" is enabled while it is disabled for enable equal to false. See the description of NormSetDefaultUnicastNack() for details on "unicast NACKing" behavior.
4.5.7.3. Return Values
This function has no return values.
4.5.8. NormSetDefaultSyncPolicy()
4.5.8.1. Synopsis
#include <normApi.h>
+                            bool           enable);
4.5.7.2. Description
This function controls the destination address of receiver feedback messages generated in response to a specific remote NORM sender corresponding to the senderNode parameter. If enable is true, "unicast NACKing" is enabled while it is disabled for enable equal to false. See the description of NormSetDefaultUnicastNack() for details on "unicast NACKing" behavior.
4.5.7.3. Return Values
This function has no return values.
4.5.8. NormSetDefaultSyncPolicy()
4.5.8.1. Synopsis
#include <normApi.h>
 
 void NormSetDefaultSyncPolicy(NormSessionHandle sessionHandle,
-                              NormSyncPolicy   syncPolicy);
4.5.8.2. Description
This function sets the default "synchronization policy" used when beginning (or restarting) reception of objects from a remote sender (i.e., "syncing" to the sender) for the given sessionHandle. The "synchronization policy" is the behavior observed by the receiver with regards to what objects it attempts to reliably receive (via transmissions of Negative Acknowledgements to the sender(s) or group as needed). There are currently two synchronization policy types defined:
NORM_SYNC_CURRENT
Attempt reception of "current" and new objects only. (default)
NORM_SYNC_ALL
Attempt recovery and reliable reception of all objects held in sender transmit object cache and newer objects.
The behavior of a receiver using the default NORM_SYNC_CURRENT policy is to attempt reliable reception only for the first received "current" and newer (with respect to the ordinal NORM object transport identifiers used by the protocol) objects from a given NORM sender. Additionally, reliable reception is only attempted when receiving a non-repair NORM_DATA message (or optionally a NORM positive acknowledgement request) from the first forward error correction (FEC) encoding block of the given object. This somewhat conservative synchronization behavior helps prevent late-joining (or otherwise "flaky" with respect to group membership) receivers from penalizing other receivers in the group by causing the sender to "rewind" and transmit older object content to satisfy the late joiner instead of moving forward with transmission of new content. For large scale, loosely-organized multicast applications, the NORM_SYNC_CURRENT policy is typically recommended.
The NORM_SYNC_ALL policy allows newly joining receivers much more aggressive behavior as they will immediately NACK for all objects from the "current" object backwards through the entire range of objects set by the NormSetRxCacheLimit() function. This behavior depends upon the sender to issue an appropriate NORM_CMD(SQUELCH) response (if applicable) to align (i.e. "synchronize") the new receiver with its current transmit object cache (similar to a "repair window"). This synchronization behavior may be useful for unicast uses of NORM or other applications where the group membership is more carefully managed and it is important that all content (including older content) is received. Note that the sender transmit cache bounds (see NormSetTxCacheBounds()) and the receiver receive cache limit (see NormSetRxCacheLimit()) settings will limit how far back onto the sender transmission history that transmitted objects can be reliably recovered from the "current" transmission point when the receiver begins reception.
When this function is not invoked, the NORM_SYNC_CURRENT behavior is observed as the default receiver synchronization policy. This call SHOULD be made before NormStartReceiver() is called.
4.5.8.3. Return Values
This function has no return values.
4.5.9. NormSetDefaultNackingMode()
4.5.9.1. Synopsis
#include <normApi.h>
+                              NormSyncPolicy   syncPolicy);
4.5.8.2. Description
This function sets the default "synchronization policy" used when beginning (or restarting) reception of objects from a remote sender (i.e., "syncing" to the sender) for the given sessionHandle. The "synchronization policy" is the behavior observed by the receiver with regards to what objects it attempts to reliably receive (via transmissions of Negative Acknowledgements to the sender(s) or group as needed). There are currently two synchronization policy types defined:
NORM_SYNC_CURRENT
Attempt reception of "current" and new objects only. (default)
NORM_SYNC_ALL
Attempt recovery and reliable reception of all objects held in sender transmit object cache and newer objects.
The behavior of a receiver using the default NORM_SYNC_CURRENT policy is to attempt reliable reception only for the first received "current" and newer (with respect to the ordinal NORM object transport identifiers used by the protocol) objects from a given NORM sender. Additionally, reliable reception is only attempted when receiving a non-repair NORM_DATA message (or optionally a NORM positive acknowledgement request) from the first forward error correction (FEC) encoding block of the given object. This somewhat conservative synchronization behavior helps prevent late-joining (or otherwise "flaky" with respect to group membership) receivers from penalizing other receivers in the group by causing the sender to "rewind" and transmit older object content to satisfy the late joiner instead of moving forward with transmission of new content. For large scale, loosely-organized multicast applications, the NORM_SYNC_CURRENT policy is typically recommended.
The NORM_SYNC_ALL policy allows newly joining receivers much more aggressive behavior as they will immediately NACK for all objects from the "current" object backwards through the entire range of objects set by the NormSetRxCacheLimit() function. This behavior depends upon the sender to issue an appropriate NORM_CMD(SQUELCH) response (if applicable) to align (i.e. "synchronize") the new receiver with its current transmit object cache (similar to a "repair window"). This synchronization behavior may be useful for unicast uses of NORM or other applications where the group membership is more carefully managed and it is important that all content (including older content) is received. Note that the sender transmit cache bounds (see NormSetTxCacheBounds()) and the receiver receive cache limit (see NormSetRxCacheLimit()) settings will limit how far back onto the sender transmission history that transmitted objects can be reliably recovered from the "current" transmission point when the receiver begins reception.
When this function is not invoked, the NORM_SYNC_CURRENT behavior is observed as the default receiver synchronization policy. This call SHOULD be made before NormStartReceiver() is called.
4.5.8.3. Return Values
This function has no return values.
4.5.9. NormSetDefaultNackingMode()
4.5.9.1. Synopsis
#include <normApi.h>
 
 void NormSetDefaultNackingMode(NormSessionHandle sessionHandle,
-                               NormNackingMode   nackingMode);
4.5.9.2. Description
This function sets the default "nacking mode" used when receiving objects for the given sessionHandle. This allows the receiver application some control of its degree of participation in the repair process. By limiting receivers to only request repair of objects in which they are really interested in receiving, some overall savings in unnecessary network loading might be realized for some applications and users. Available nacking modes include:
NORM_NACK_NONE
Do not transmit any repair requests for the newly received object.
NORM_NACK_INFO_ONLY
Transmit repair requests for NORM_INFO content only as needed.
NORM_NACK_NORMAL
Transmit repair requests for entire object as needed.
This function specifies the default behavior with respect to any new sender or object. This default behavior may be overridden for specific sender nodes or specific object using NormNodeSetNackingMode() or NormObjectSetNackingMode(), respectively. The receiver application's use of NORM_NACK_NONE essentially disables a guarantee of reliable reception, although the receiver may still take advantage of sender repair transmissions in response to other receivers' requests. When the sender provides, NORM_INFO content for transmitted objects, the NORM_NACK_INFO_ONLY mode may allows the receiver to reliably receive object context information from which it may choose to "upgrade" its nackingMode for the specific object via the NormObjectSetNackingMode() call. Similarly, the receiver may changes its default nackingMode with respect to specific senders via the NormNodeSetNackingMode() call. The default "default nackingMode" when this call is not made is NORM_NACK_NORMAL.
4.5.9.3. Return Values
This function has no return values.
4.5.10. NormNodeSetNackingMode()
4.5.10.1. Synopsis
#include <normApi.h>
+                               NormNackingMode   nackingMode);
4.5.9.2. Description
This function sets the default "nacking mode" used when receiving objects for the given sessionHandle. This allows the receiver application some control of its degree of participation in the repair process. By limiting receivers to only request repair of objects in which they are really interested in receiving, some overall savings in unnecessary network loading might be realized for some applications and users. Available nacking modes include:
NORM_NACK_NONE
Do not transmit any repair requests for the newly received object.
NORM_NACK_INFO_ONLY
Transmit repair requests for NORM_INFO content only as needed.
NORM_NACK_NORMAL
Transmit repair requests for entire object as needed.
This function specifies the default behavior with respect to any new sender or object. This default behavior may be overridden for specific sender nodes or specific object using NormNodeSetNackingMode() or NormObjectSetNackingMode(), respectively. The receiver application's use of NORM_NACK_NONE essentially disables a guarantee of reliable reception, although the receiver may still take advantage of sender repair transmissions in response to other receivers' requests. When the sender provides, NORM_INFO content for transmitted objects, the NORM_NACK_INFO_ONLY mode may allows the receiver to reliably receive object context information from which it may choose to "upgrade" its nackingMode for the specific object via the NormObjectSetNackingMode() call. Similarly, the receiver may changes its default nackingMode with respect to specific senders via the NormNodeSetNackingMode() call. The default "default nackingMode" when this call is not made is NORM_NACK_NORMAL.
4.5.9.3. Return Values
This function has no return values.
4.5.10. NormNodeSetNackingMode()
4.5.10.1. Synopsis
#include <normApi.h>
 
 void NormNodeSetNackingMode(NormNodeHandle  nodeHandle,
-                            NormNackingMode nackingMode);
4.5.10.2. Description
This function sets the default "nacking mode" used for receiving new objects from a specific sender as identified by the nodeHandle parameter. This overrides the default nackingMode set for the receive session. See NormSetDefaultNackingMode() for a description of possible nackingMode parameter values and other related information.
4.5.10.3. Return Values
This function has no return values.
4.5.11. NormObjectSetNackingMode()
4.5.11.1. Synopsis
#include <normApi.h>
+                            NormNackingMode nackingMode);
4.5.10.2. Description
This function sets the default "nacking mode" used for receiving new objects from a specific sender as identified by the nodeHandle parameter. This overrides the default nackingMode set for the receive session. See NormSetDefaultNackingMode() for a description of possible nackingMode parameter values and other related information.
4.5.10.3. Return Values
This function has no return values.
4.5.11. NormObjectSetNackingMode()
4.5.11.1. Synopsis
#include <normApi.h>
 
 void NormObjectSetNackingMode(NormObjectHandle objectHandle,
-                              NormNackingMode  nackingMode);
4.5.11.2. Description
This function sets the "nacking mode" used for receiving a specific transport object as identified by the objectHandle parameter. This overrides the default nacking mode set for the applicable sender node. See NormSetDefaultNackingMode() for a description of possible nackingMode parameter values and other related information.
4.5.11.3. Return Values
This function has no return values.
4.5.12. NormSetDefaultRepairBoundary()
4.5.12.1. Synopsis
#include <normApi.h>
+                              NormNackingMode  nackingMode);
4.5.11.2. Description
This function sets the "nacking mode" used for receiving a specific transport object as identified by the objectHandle parameter. This overrides the default nacking mode set for the applicable sender node. See NormSetDefaultNackingMode() for a description of possible nackingMode parameter values and other related information.
4.5.11.3. Return Values
This function has no return values.
4.5.12. NormSetDefaultRepairBoundary()
4.5.12.1. Synopsis
#include <normApi.h>
 
 void NormSetDefaultRepairBoundary(NormSessionHandle  sessionHandle,
-                                  NormRepairBoundary repairBoundary);
4.5.12.2. Description
This function allows the receiver application to customize, for a given sessionHandle, at what points the receiver initiates the NORM NACK repair process during protocol operation. Normally, the NORM receiver initiates NACKing for repairs at the FEC code block and transport object boundaries. For smaller block sizes, the NACK repair process is often/quickly initiated and the repair of an object will occur, as needed, during the transmission of the object. This default operation corresponds to repairBoundary equal to NORM_BOUNDARY_BLOCK. Using this function, the application may alternatively, setting repairBoundary equal to NORM_BOUNDARY_OBJECT, cause the protocol to defer NACK process initiation until the current transport object has been completely transmitted.
4.5.12.3. Return Values
This function has no return values.
4.5.13. NormNodeSetRepairBoundary()
4.5.13.1. Synopsis
#include <normApi.h>
+                                  NormRepairBoundary repairBoundary);
4.5.12.2. Description
This function allows the receiver application to customize, for a given sessionHandle, at what points the receiver initiates the NORM NACK repair process during protocol operation. Normally, the NORM receiver initiates NACKing for repairs at the FEC code block and transport object boundaries. For smaller block sizes, the NACK repair process is often/quickly initiated and the repair of an object will occur, as needed, during the transmission of the object. This default operation corresponds to repairBoundary equal to NORM_BOUNDARY_BLOCK. Using this function, the application may alternatively, setting repairBoundary equal to NORM_BOUNDARY_OBJECT, cause the protocol to defer NACK process initiation until the current transport object has been completely transmitted.
4.5.12.3. Return Values
This function has no return values.
4.5.13. NormNodeSetRepairBoundary()
4.5.13.1. Synopsis
#include <normApi.h>
 
 void NormNodeSetRepairBoundary(NormNodeHandle     nodeHandle,
-                               NormRepairBoundary repairBoundary);
4.5.13.2. Description
This function allows the receiver application to customize, for the specific remote sender referenced by the nodeHandle parameter, at what points the receiver initiates the NORM NACK repair process during protocol operation. See the description of NormSetDefaultRepairBoundary() for further details on the impact of setting the NORM receiver repair boundary and possible values for the repairBoundary parameter.
4.5.13.3. Return Values
This function has no return values.
4.5.14. NormSetDefaultRxRobustFactor()
4.5.14.1. Synopsis
#include <normApi.h>
+                               NormRepairBoundary repairBoundary);
4.5.13.2. Description
This function allows the receiver application to customize, for the specific remote sender referenced by the nodeHandle parameter, at what points the receiver initiates the NORM NACK repair process during protocol operation. See the description of NormSetDefaultRepairBoundary() for further details on the impact of setting the NORM receiver repair boundary and possible values for the repairBoundary parameter.
4.5.13.3. Return Values
This function has no return values.
4.5.14. NormSetDefaultRxRobustFactor()
4.5.14.1. Synopsis
#include <normApi.h>
 
 void NormSetDefaultRxRobustFactor(NormSessionHandle sessionHandle,
-                                  int               rxRobustFactor);
4.5.14.2. Description
This routine controls how persistently NORM receivers will maintain state for sender(s) and continue to request repairs from the sender(s) even when packet reception has ceased. The rxRobustFactor value determines how many times a NORM receiver will self-initiate NACKing (repair requests) upon cessation of packet reception from a sender. The default value is 20. Setting rxRobustFactor to -1 will make the NORM receiver infinitely persistent (i.e., it will continue to NACK indefinitely as long as it is missing data content). It is important to note that the NormSetTxRobustFactor() also affects receiver operation in setting the time interval that is used to gauge that sender packet transmission has ceased (i.e., the sender inactivity timeout). This "timeout" interval is a equal of (2 * GRTT * txRobustFactor). Thus the overall timeout before a NORM receiver quits NACKing is (rxRobustFactor * 2 * GRTT * txRobustFactor).
The NormNodeSetRxRobustFactor() function can be used to control this behavior on a per-sender basis. When a new remote sender is detected, the default rxRobustFactor set here is used. Again, the default value is 20.
4.5.14.3. Return Values
This function has no return values.
4.5.15. NormNodeSetRxRobustFactor()
4.5.15.1. Synopsis
#include <normApi.h>
+                                  int               rxRobustFactor);
4.5.14.2. Description
This routine controls how persistently NORM receivers will maintain state for sender(s) and continue to request repairs from the sender(s) even when packet reception has ceased. The rxRobustFactor value determines how many times a NORM receiver will self-initiate NACKing (repair requests) upon cessation of packet reception from a sender. The default value is 20. Setting rxRobustFactor to -1 will make the NORM receiver infinitely persistent (i.e., it will continue to NACK indefinitely as long as it is missing data content). It is important to note that the NormSetTxRobustFactor() also affects receiver operation in setting the time interval that is used to gauge that sender packet transmission has ceased (i.e., the sender inactivity timeout). This "timeout" interval is a equal of (2 * GRTT * txRobustFactor). Thus the overall timeout before a NORM receiver quits NACKing is (rxRobustFactor * 2 * GRTT * txRobustFactor).
The NormNodeSetRxRobustFactor() function can be used to control this behavior on a per-sender basis. When a new remote sender is detected, the default rxRobustFactor set here is used. Again, the default value is 20.
4.5.14.3. Return Values
This function has no return values.
4.5.15. NormNodeSetRxRobustFactor()
4.5.15.1. Synopsis
#include <normApi.h>
 
 void NormNodeSetRxRobustFactor(NormNodeHandle nodeHandle,
-                               int            rxRobustFactor);
4.5.15.2. Description
This routine sets the rxRobustFactor as described in NormSetDefaultRxRobustFactor() for an individual remote sender identified by the nodeHandle parameter. See the description of NormSetDefaultRxRobustFactor() for details
4.5.15.3. Return Values
This function has no return values.
4.5.16. NormStreamRead()
4.5.16.1. Synopsis
#include <normApi.h>
+                               int            rxRobustFactor);
4.5.15.2. Description
This routine sets the rxRobustFactor as described in NormSetDefaultRxRobustFactor() for an individual remote sender identified by the nodeHandle parameter. See the description of NormSetDefaultRxRobustFactor() for details
4.5.15.3. Return Values
This function has no return values.
4.5.16. NormStreamRead()
4.5.16.1. Synopsis
#include <normApi.h>
 
 bool NormStreamRead(NormObjectHandle streamHandle,
                     char*            buffer
-                    unsigned int*    numBytes);
4.5.16.2. Description
This function can be used by the receiver application to read any available data from an incoming NORM stream. NORM receiver applications "learn" of available NORM streams via NORM_RX_OBJECT_NEW notification events. The streamHandle parameter here must correspond to a valid NormObjectHandle value provided during such a prior NORM_RX_OBJECT_NEW notification. The buffer parameter must be a pointer to an array where the received data can be stored of a length as referenced by the numBytes pointer. On successful completion, the numBytes storage will be modified to indicate the actual number of bytes copied into the provided buffer. If the numBytes storage is modified to a zero value, this indicates that no stream data was currently available for reading.
Note that NormStreamRead() is never a blocking call and only returns failure (false) when a break in the integrity of the received stream occurs. The NORM_RX_OBJECT_UPDATE provides an indication to when there is stream data available for reading. When such notification occurs, the application should repeatedly read from the stream until the numBytes storage is set to zero, even if a false value is returned. Additional NORM_RX_OBJECT_UPDATE notifications might not be posted until the application has read all available data.
4.5.16.3. Return Values
This function normally returns a value of true. However, if a break in the integrity of the reliable received stream occurs (or the stream has been ended by the sender), a value of false is returned to indicate the break. Unless the stream has been ended (and the receiver application will receive NORM_RX_OBJECT_COMPLETED notification for the stream in that case), the application may continue to read from the stream as the NORM protocol will automatically "resync" to streams, even if network conditions are sufficiently poor that breaks in reliability occur. If such a "break" and "resync" occurs, the application may be able to leverage other NORM API calls such as NormStreamSeekMsgStart() or NormStreamGetReadOffset() if needed to recover its alignment with received stream content. This depends upon the nature of the application and its stream content.
4.5.17. NormStreamSeekMsgStart()
4.5.17.1. Synopsis
#include <normApi.h>
+                    unsigned int*    numBytes);
4.5.16.2. Description
This function can be used by the receiver application to read any available data from an incoming NORM stream. NORM receiver applications "learn" of available NORM streams via NORM_RX_OBJECT_NEW notification events. The streamHandle parameter here must correspond to a valid NormObjectHandle value provided during such a prior NORM_RX_OBJECT_NEW notification. The buffer parameter must be a pointer to an array where the received data can be stored of a length as referenced by the numBytes pointer. On successful completion, the numBytes storage will be modified to indicate the actual number of bytes copied into the provided buffer. If the numBytes storage is modified to a zero value, this indicates that no stream data was currently available for reading.
Note that NormStreamRead() is never a blocking call and only returns failure (false) when a break in the integrity of the received stream occurs. The NORM_RX_OBJECT_UPDATE provides an indication to when there is stream data available for reading. When such notification occurs, the application should repeatedly read from the stream until the numBytes storage is set to zero, even if a false value is returned. Additional NORM_RX_OBJECT_UPDATE notifications might not be posted until the application has read all available data.
4.5.16.3. Return Values
This function normally returns a value of true. However, if a break in the integrity of the reliable received stream occurs (or the stream has been ended by the sender), a value of false is returned to indicate the break. Unless the stream has been ended (and the receiver application will receive NORM_RX_OBJECT_COMPLETED notification for the stream in that case), the application may continue to read from the stream as the NORM protocol will automatically "resync" to streams, even if network conditions are sufficiently poor that breaks in reliability occur. If such a "break" and "resync" occurs, the application may be able to leverage other NORM API calls such as NormStreamSeekMsgStart() or NormStreamGetReadOffset() if needed to recover its alignment with received stream content. This depends upon the nature of the application and its stream content.
4.5.17. NormStreamSeekMsgStart()
4.5.17.1. Synopsis
#include <normApi.h>
 
-bool NormStreamSeekMsgStart(NormObjectHandle streamHandle);
4.5.17.2. Description
This function advances the read offset of the receive stream referenced by the streamHandle parameter to align with the next available message boundary. Message boundaries are defined by the sender application using the NormStreamMarkEom() call. Note that any received data prior to the next message boundary is discarded by the NORM protocol engine and is not available to the application (i.e., there is currently no "rewind" function for a NORM stream). Also note this call cannot be used to skip messages. Once a valid message boundary is found, the application must read from the stream using NormStreamRead() to further advance the read offset. The current offset (in bytes) for the stream can be retrieved via NormStreamGetReadOffset().
4.5.17.3. Return Values
This function returns a value of true when start-of-message is found. The next call to NormStreamRead() will retrieve data aligned with the message start. If no new message boundary is found in the buffered receive data for the stream, the function returns a value of false. In this case, the application should defer repeating a call to this function until a subsequent NORM_RX_OBJECT_UPDATE notification is posted.
4.5.18. NormStreamGetReadOffset()
4.5.18.1. Synopsis
#include <normApi.h>
+bool NormStreamSeekMsgStart(NormObjectHandle streamHandle);
4.5.17.2. Description
This function advances the read offset of the receive stream referenced by the streamHandle parameter to align with the next available message boundary. Message boundaries are defined by the sender application using the NormStreamMarkEom() call. Note that any received data prior to the next message boundary is discarded by the NORM protocol engine and is not available to the application (i.e., there is currently no "rewind" function for a NORM stream). Also note this call cannot be used to skip messages. Once a valid message boundary is found, the application must read from the stream using NormStreamRead() to further advance the read offset. The current offset (in bytes) for the stream can be retrieved via NormStreamGetReadOffset().
4.5.17.3. Return Values
This function returns a value of true when start-of-message is found. The next call to NormStreamRead() will retrieve data aligned with the message start. If no new message boundary is found in the buffered receive data for the stream, the function returns a value of false. In this case, the application should defer repeating a call to this function until a subsequent NORM_RX_OBJECT_UPDATE notification is posted.
4.5.18. NormStreamGetReadOffset()
4.5.18.1. Synopsis
#include <normApi.h>
 
-unsigned long NormStreamGetReadOffset(NormObjectHandle streamHandle);
4.5.18.2. Description
This function retrieves the current read offset value for the receive stream indicated by the streamHandle parameter. Note that for very long-lived streams, this value may wrap. Thus, in general, applications should not be highly dependent upon the stream offset, but this feature may be valuable for certain applications which associate some application context with stream position.
4.5.18.3. Return Values
This function returns the current read offset in bytes. The return value is undefined for sender streams. There is no error result.
4.6. NORM Object Functions
The functions described in this section may be used for sender or receiver purposes to manage transmission and reception of NORM transport objects. In most cases, the receiver will be the typical user of these functions to retrieve additional information on newly-received objects. All of these functions require a valid NormObjectHandle argument which specifies the applicable object. Note that NormObjectHandle values obtained from a NormEvent notification may be considered valid only until a subsequent call to NormGetNextEvent(), unless explicitly retained by the application (see NormObjectRetain()). NormObjectHandle values obtained as a result of NormFileEnqueue(), NormDataEnqueue(), or NormStreamOpen() calls can be considered valid only until a corresponding NORM_TX_OBJECT_PURGED notification is posted or the object is dequeued using NormObjectCancel(), unless, again, otherwise explicitly retained (see NormObjectRetain()).
4.6.1. NormObjectGetType()
4.6.1.1. Synopsis
#include <normApi.h>
+unsigned long NormStreamGetReadOffset(NormObjectHandle streamHandle);
4.5.18.2. Description
This function retrieves the current read offset value for the receive stream indicated by the streamHandle parameter. Note that for very long-lived streams, this value may wrap. Thus, in general, applications should not be highly dependent upon the stream offset, but this feature may be valuable for certain applications which associate some application context with stream position.
4.5.18.3. Return Values
This function returns the current read offset in bytes. The return value is undefined for sender streams. There is no error result.
4.6. NORM Object Functions
The functions described in this section may be used for sender or receiver purposes to manage transmission and reception of NORM transport objects. In most cases, the receiver will be the typical user of these functions to retrieve additional information on newly-received objects. All of these functions require a valid NormObjectHandle argument which specifies the applicable object. Note that NormObjectHandle values obtained from a NormEvent notification may be considered valid only until a subsequent call to NormGetNextEvent(), unless explicitly retained by the application (see NormObjectRetain()). NormObjectHandle values obtained as a result of NormFileEnqueue(), NormDataEnqueue(), or NormStreamOpen() calls can be considered valid only until a corresponding NORM_TX_OBJECT_PURGED notification is posted or the object is dequeued using NormObjectCancel(), unless, again, otherwise explicitly retained (see NormObjectRetain()).
4.6.1. NormObjectGetType()
4.6.1.1. Synopsis
#include <normApi.h>
 
-NormObjectType NormObjectGetType(NormObjectHandle objectHandle);
4.6.1.2. Description
This function can be used to determine the object type ((NORM_OBJECT_DAT, NORM_OBJECT_FILE, or NORM_OBJECT_STREAM) for the NORM transport object identified by the objectHandle parameter. The objectHandle must refer to a current, valid transport object.
4.6.1.3. Return Values
This function returns the NORM object type. Valid NORM object types include NORM_OBJECT_DATA, NORM_OBJECT_FILE, or NORM_OBJECT_STREAM. A type value of NORM_OBJECT_NONE will be returned for an objectHandle value of NORM_OBJECT_INVALID.
4.6.2. NormObjectHasInfo()
4.6.2.1. Synopsis
#include <normApi.h>
+NormObjectType NormObjectGetType(NormObjectHandle objectHandle);
4.6.1.2. Description
This function can be used to determine the object type ((NORM_OBJECT_DAT, NORM_OBJECT_FILE, or NORM_OBJECT_STREAM) for the NORM transport object identified by the objectHandle parameter. The objectHandle must refer to a current, valid transport object.
4.6.1.3. Return Values
This function returns the NORM object type. Valid NORM object types include NORM_OBJECT_DATA, NORM_OBJECT_FILE, or NORM_OBJECT_STREAM. A type value of NORM_OBJECT_NONE will be returned for an objectHandle value of NORM_OBJECT_INVALID.
4.6.2. NormObjectHasInfo()
4.6.2.1. Synopsis
#include <normApi.h>
 
-bool NormObjectHasInfo(NormObjectHandle objectHandle);
4.6.2.2. Description
This function can be used to determine if the sender has associated any NORM_INFO content with the transport object specified by the objectHandle parameter. This can even be used before the NORM_INFO content is delivered to the receiver and a NORM_RX_OBJECT_INFO notification is posted.
4.6.2.3. Return Values
A value of true is returned if NORM_INFO is (or will be) available for the specified transport object. A value of false is returned otherwise.
4.6.3. NormObjectGetInfoLength()
4.6.3.1. Synopsis
#include <normApi.h>
+bool NormObjectHasInfo(NormObjectHandle objectHandle);
4.6.2.2. Description
This function can be used to determine if the sender has associated any NORM_INFO content with the transport object specified by the objectHandle parameter. This can even be used before the NORM_INFO content is delivered to the receiver and a NORM_RX_OBJECT_INFO notification is posted.
4.6.2.3. Return Values
A value of true is returned if NORM_INFO is (or will be) available for the specified transport object. A value of false is returned otherwise.
4.6.3. NormObjectGetInfoLength()
4.6.3.1. Synopsis
#include <normApi.h>
 
-unsigned short NormObjectGetInfoLength(NormObjectHandle objectHandle);
4.6.3.2. Description
This function can be used to determine the length of currently available NORM_INFO content (if any) associated with the transport object referenced by the objectHandle parameter.
4.6.3.3. Return Values
The length of the NORM_INFO content, in bytes, of currently available for the specified transport object is returned. A value of 0 is returned if no NORM_INFO content is currently available or associated with the object.
4.6.4. NormObjectGetInfo()
4.6.4.1. Synopsis
#include <normApi.h>
+unsigned short NormObjectGetInfoLength(NormObjectHandle objectHandle);
4.6.3.2. Description
This function can be used to determine the length of currently available NORM_INFO content (if any) associated with the transport object referenced by the objectHandle parameter.
4.6.3.3. Return Values
The length of the NORM_INFO content, in bytes, of currently available for the specified transport object is returned. A value of 0 is returned if no NORM_INFO content is currently available or associated with the object.
4.6.4. NormObjectGetInfo()
4.6.4.1. Synopsis
#include <normApi.h>
 
 unsigned short NormObjectGetInfo(NormObjectHandle         objectHandle,
                                  char*                    buffer,
-                                 unsigned short           bufferLen);
4.6.4.2. Description
This function copies any NORM_INFO content associated (by the sender application) with the transport object specified by objectHandle into the provided memory space referenced by the buffer parameter. The bufferLen parameter indicates the length of the buffer space in bytes. If the provided bufferLen is less than the actual NORM_INFO length, a partial copy will occur. The actual length of NORM_INFO content available for the specified object is returned. However, note that until a NORM_RX_OBJECT_INFO notification is posted to the receive application, no NORM_INFO content is available and a zero result will be returned, even if NORM_INFO content may be subsequently available. The NormObjectHasInfo() call can be used to determine if any NORM_INFO content will ever be available for a specified transport object (i.e., determine if the sender has associated any NORM_INFO with the object in question).
4.6.4.3. Return Values
The actual length of currently available NORM_INFO content for the specified transport object is returned. This function can be used to determine the length of NORM_INFO content for the object even if a NULL buffer value and zero bufferLen is provided. A zero value is returned if NORM_INFO content has not yet been received (or is non-existent) for the specified object.
4.6.5. NormObjectGetSize()
4.6.5.1. Synopsis
#include <normApi.h>
+                                 unsigned short           bufferLen);
4.6.4.2. Description
This function copies any NORM_INFO content associated (by the sender application) with the transport object specified by objectHandle into the provided memory space referenced by the buffer parameter. The bufferLen parameter indicates the length of the buffer space in bytes. If the provided bufferLen is less than the actual NORM_INFO length, a partial copy will occur. The actual length of NORM_INFO content available for the specified object is returned. However, note that until a NORM_RX_OBJECT_INFO notification is posted to the receive application, no NORM_INFO content is available and a zero result will be returned, even if NORM_INFO content may be subsequently available. The NormObjectHasInfo() call can be used to determine if any NORM_INFO content will ever be available for a specified transport object (i.e., determine if the sender has associated any NORM_INFO with the object in question).
4.6.4.3. Return Values
The actual length of currently available NORM_INFO content for the specified transport object is returned. This function can be used to determine the length of NORM_INFO content for the object even if a NULL buffer value and zero bufferLen is provided. A zero value is returned if NORM_INFO content has not yet been received (or is non-existent) for the specified object.
4.6.5. NormObjectGetSize()
4.6.5.1. Synopsis
#include <normApi.h>
 
-NormSize NormObjectGetSize(NormObjectHandle objectHandle);
4.6.5.2. Description
This function can be used to determine the size (in bytes) of the transport object specified by the objectHandle parameter. NORM can support large object sizes for the NORM_OBJECT_FILE type, so typically the NORM library is built with any necessary, related macros defined such that operating system large file support is enabled (e.g., "#define _FILE_OFFSET_BITS 64" or equivalent). The NormSize type is defined accordingly, so the application should be built with the same large file support configuration.
For objects of type NORM_OBJECT_STREAM, the size returned here corresponds to the stream buffer size set by the sender application when opening the referenced stream object.
4.6.5.3. Return Values
A size of the data content of the specified object, in bytes, is returned. Note that it may be possible that some objects have zero data content, but do have NORM_INFO content available.
4.6.6. NormObjectGetBytesPending()
4.6.6.1. Synopsis
#include <normApi.h>
+NormSize NormObjectGetSize(NormObjectHandle objectHandle);
4.6.5.2. Description
This function can be used to determine the size (in bytes) of the transport object specified by the objectHandle parameter. NORM can support large object sizes for the NORM_OBJECT_FILE type, so typically the NORM library is built with any necessary, related macros defined such that operating system large file support is enabled (e.g., "#define _FILE_OFFSET_BITS 64" or equivalent). The NormSize type is defined accordingly, so the application should be built with the same large file support configuration.
For objects of type NORM_OBJECT_STREAM, the size returned here corresponds to the stream buffer size set by the sender application when opening the referenced stream object.
4.6.5.3. Return Values
A size of the data content of the specified object, in bytes, is returned. Note that it may be possible that some objects have zero data content, but do have NORM_INFO content available.
4.6.6. NormObjectGetBytesPending()
4.6.6.1. Synopsis
#include <normApi.h>
 
-NormSize NormObjectGetBytesPending(NormObjectHandle objectHandle);
4.6.6.2. Description
This function can be used to determine the progress of reception of the NORM transport object identified by the objectHandle parameter. This function indicates the number of bytes that are pending reception (I.e., when the object is completely received, "bytes pending" will equal ZERO). This function is not necessarily applicable to objects of type NORM_OBJECT_STREAM which do not have a finite size. Note it is possible that this function might also be useful to query the "transmit pending" status of sender objects, but it does not account for pending FEC repair transmissions and thus may not produce useful results for this purpose.
4.6.6.3. Return Values
A number of object source data bytes pending reception (or transmission) is returned.
4.6.7. NormObjectCancel()
4.6.7.1. Synopsis
#include <normApi.h>
+NormSize NormObjectGetBytesPending(NormObjectHandle objectHandle);
4.6.6.2. Description
This function can be used to determine the progress of reception of the NORM transport object identified by the objectHandle parameter. This function indicates the number of bytes that are pending reception (I.e., when the object is completely received, "bytes pending" will equal ZERO). This function is not necessarily applicable to objects of type NORM_OBJECT_STREAM which do not have a finite size. Note it is possible that this function might also be useful to query the "transmit pending" status of sender objects, but it does not account for pending FEC repair transmissions and thus may not produce useful results for this purpose.
4.6.6.3. Return Values
A number of object source data bytes pending reception (or transmission) is returned.
4.6.7. NormObjectCancel()
4.6.7.1. Synopsis
#include <normApi.h>
 
-void NormObjectCancel(NormObjectHandle objectHandle);
4.6.7.2. Description
This function immediately cancels the transmission of a local sender transport object or the reception of a specified object from a remote sender as specified by the objectHandle parameter. The objectHandle must refer to a currently valid NORM transport object. Any resources used by the transport object in question are immediately freed unless the object has been otherwise retained by the application via the NormObjectRetain() call. Unless the application has retained the object in such fashion, the object in question should be considered invalid and the application must not again reference the objectHandle after this call is made.
If the canceled object is a sender object not completely received by participating receivers, the receivers will be informed of the object's cancellation via the NORM protocol NORM_CMD(SQUELCH) message in response to any NACKs requesting repair or retransmission of the applicable object. In the case of receive objects, the NORM receiver will not make further requests for repair of the indicated object, but furthermore, will acknowledge the object as completed with respect to any associated positive acknowledgement requests (see NormSetWatermark()).
4.6.7.3. Return Values
This function has no return value.
4.6.8. NormObjectRetain()
4.6.8.1. Synopsis
#include <normApi.h>
+void NormObjectCancel(NormObjectHandle objectHandle);
4.6.7.2. Description
This function immediately cancels the transmission of a local sender transport object or the reception of a specified object from a remote sender as specified by the objectHandle parameter. The objectHandle must refer to a currently valid NORM transport object. Any resources used by the transport object in question are immediately freed unless the object has been otherwise retained by the application via the NormObjectRetain() call. Unless the application has retained the object in such fashion, the object in question should be considered invalid and the application must not again reference the objectHandle after this call is made.
If the canceled object is a sender object not completely received by participating receivers, the receivers will be informed of the object's cancellation via the NORM protocol NORM_CMD(SQUELCH) message in response to any NACKs requesting repair or retransmission of the applicable object. In the case of receive objects, the NORM receiver will not make further requests for repair of the indicated object, but furthermore, will acknowledge the object as completed with respect to any associated positive acknowledgement requests (see NormSetWatermark()).
4.6.7.3. Return Values
This function has no return value.
4.6.8. NormObjectRetain()
4.6.8.1. Synopsis
#include <normApi.h>
 
-void NormObjectRetain(NormObjectHandle objectHandle);
4.6.8.2. Description
This function "retains" the objectHandle and any state associated with it for further use by the application even when the NORM protocol engine may no longer require access to the associated transport object. Normally, the application is guaranteed that a given NormObjectHandle is valid only while it is being actively transported by NORM (i.e., for sender objects, from the time an object is created by the application until it is canceled by the application or purged (see the NORM_TX_OBJECT_PURGED notification) by the protocol engine, or, for receiver objects, from the time of the object's NORM_RX_OBJECT_NEW notification until its reception is canceled by the application or a NORM_RX_OBJECT_COMPLETED or NORM_RX_OBJECT_ABORTED notification is posted). Note that an application may refer to a given object after any related notification until the application makes a subsequent call to NormGetNextEvent().
When the application makes a call to NormObjectRetain() for a given objectHandle, the application may use that objectHandle value in any NORM API calls until the application makes a call to NormObjectRelease() for the given object. Note that the application MUST make a corresponding call to NormObjectRelease() for each call it has made to NormObjectRetain() in order to free any system resources (i.e., memory) used by that object. Also note that retaining a receive object also automatically retains any state associated with the NormNodeHandle corresponding to the remote sender of that receive object so that the application may use NORM node API calls for the value returned by NormObjectGetSender() as needed.
4.6.8.3. Return Values
This function has no return value.
4.6.9. NormObjectRelease()
4.6.9.1. Synopsis
#include <normApi.h>
+void NormObjectRetain(NormObjectHandle objectHandle);
4.6.8.2. Description
This function "retains" the objectHandle and any state associated with it for further use by the application even when the NORM protocol engine may no longer require access to the associated transport object. Normally, the application is guaranteed that a given NormObjectHandle is valid only while it is being actively transported by NORM (i.e., for sender objects, from the time an object is created by the application until it is canceled by the application or purged (see the NORM_TX_OBJECT_PURGED notification) by the protocol engine, or, for receiver objects, from the time of the object's NORM_RX_OBJECT_NEW notification until its reception is canceled by the application or a NORM_RX_OBJECT_COMPLETED or NORM_RX_OBJECT_ABORTED notification is posted). Note that an application may refer to a given object after any related notification until the application makes a subsequent call to NormGetNextEvent().
When the application makes a call to NormObjectRetain() for a given objectHandle, the application may use that objectHandle value in any NORM API calls until the application makes a call to NormObjectRelease() for the given object. Note that the application MUST make a corresponding call to NormObjectRelease() for each call it has made to NormObjectRetain() in order to free any system resources (i.e., memory) used by that object. Also note that retaining a receive object also automatically retains any state associated with the NormNodeHandle corresponding to the remote sender of that receive object so that the application may use NORM node API calls for the value returned by NormObjectGetSender() as needed.
4.6.8.3. Return Values
This function has no return value.
4.6.9. NormObjectRelease()
4.6.9.1. Synopsis
#include <normApi.h>
 
-void NormObjectRelease(NormObjectHandle objectHandle);
4.6.9.2. Description
This function complements the NormObjectRetain() call by immediately freeing any resources associated with the given objectHandle, assuming the underlying NORM protocol engine no longer requires access to the corresponding transport object. Note the NORM protocol engine retains/releases state for associated objects for its own needs and thus it is very unsafe for an application to call NormObjectRelease() for an objectHandle for which it has not previously explicitly retained via NormObjectRetain().
4.6.9.3. Return Values
This function has no return value.
4.6.10. NormFileGetName()
4.6.10.1. Synopsis
#include <normApi.h>
+void NormObjectRelease(NormObjectHandle objectHandle);
4.6.9.2. Description
This function complements the NormObjectRetain() call by immediately freeing any resources associated with the given objectHandle, assuming the underlying NORM protocol engine no longer requires access to the corresponding transport object. Note the NORM protocol engine retains/releases state for associated objects for its own needs and thus it is very unsafe for an application to call NormObjectRelease() for an objectHandle for which it has not previously explicitly retained via NormObjectRetain().
4.6.9.3. Return Values
This function has no return value.
4.6.10. NormFileGetName()
4.6.10.1. Synopsis
#include <normApi.h>
 
 bool NormFileGetName(NormObjectHandle objectHandle,
                      char*            nameBuffer,
-                     unsigned int     bufferLen);
4.6.10.2. Description
This function copies the name, as a NULL-terminated string, of the file object specified by the objectHandle parameter into the nameBuffer of length bufferLen bytes provided by the application. The objectHandle parameter must refer to a valid NormObjectHandle for an object of type NORM_OBJECT_FILE. If the actual name is longer than the provided bufferLen, a partial copy will occur. Note that the file name consists of the entire path name of the specified file object and the application should give consideration to operating system file path lengths when providing the nameBuffer.
4.6.10.3. Return Values
This function returns true upon success and false upon failure. Possible failure conditions include the objectHandle does not refer to an object of type NORM_OBJECT_FILE.
4.6.11. NormFileRename()
4.6.11.1. Synopsis
#include <normApi.h>
+                     unsigned int     bufferLen);
4.6.10.2. Description
This function copies the name, as a NULL-terminated string, of the file object specified by the objectHandle parameter into the nameBuffer of length bufferLen bytes provided by the application. The objectHandle parameter must refer to a valid NormObjectHandle for an object of type NORM_OBJECT_FILE. If the actual name is longer than the provided bufferLen, a partial copy will occur. Note that the file name consists of the entire path name of the specified file object and the application should give consideration to operating system file path lengths when providing the nameBuffer.
4.6.10.3. Return Values
This function returns true upon success and false upon failure. Possible failure conditions include the objectHandle does not refer to an object of type NORM_OBJECT_FILE.
4.6.11. NormFileRename()
4.6.11.1. Synopsis
#include <normApi.h>
 
 bool NormFileRename(NormObjectHandle objectHandle,
-                    const char*      fileName);
4.6.11.2. Description
This function renames the file used to store content for the NORM_OBJECT_FILE transport object specified by the objectHandle parameter. This allows receiver applications to rename (or move) received files as needed. NORM uses temporary file names for received files until the application explicitly renames the file. For example, sender applications may choose to use the NORM_INFO content associated with a file object to provide name and/or typing information to receivers. The fileName parameter must be a NULL-terminated string which should specify the full desired path name to be used. NORM will attempt to create sub-directories as needed to satisfy the request. Note that existing files of the same name may be overwritten.
4.6.11.3. Return Values
This function returns true upon success and false upon failure. Possible failure conditions include the case where the objectHandle does not refer to an object of type NORM_OBJECT_FILE and where NORM was unable to successfully create any needed directories and/or the file itself.
4.6.12. NormDataAccessData()
4.6.12.1. Synopsis
#include <normApi.h>
+                    const char*      fileName);
4.6.11.2. Description
This function renames the file used to store content for the NORM_OBJECT_FILE transport object specified by the objectHandle parameter. This allows receiver applications to rename (or move) received files as needed. NORM uses temporary file names for received files until the application explicitly renames the file. For example, sender applications may choose to use the NORM_INFO content associated with a file object to provide name and/or typing information to receivers. The fileName parameter must be a NULL-terminated string which should specify the full desired path name to be used. NORM will attempt to create sub-directories as needed to satisfy the request. Note that existing files of the same name may be overwritten.
4.6.11.3. Return Values
This function returns true upon success and false upon failure. Possible failure conditions include the case where the objectHandle does not refer to an object of type NORM_OBJECT_FILE and where NORM was unable to successfully create any needed directories and/or the file itself.
4.6.12. NormDataAccessData()
4.6.12.1. Synopsis
#include <normApi.h>
 
-const char* NormDataAccessData(NormObjectHandle objectHandle);
4.6.12.2. Description
This function allows the application to access the data storage area associated with a transport object of type NORM_OBJECT_DATA. For example, the application may use this function to copy the received data content for its own use. Alternatively, the application may establish "ownership" for the allocated memory space using the NormDataDetachData() function if it is desired to avoid the copy.
If the object specified by the objectHandle parameter has no data content (or is not of type NORM_OBJECT_DATA), a NULL value may be returned. The application MUST NOT attempt to modify the memory space used by NORM_OBJECT_DATA objects during the time an associated objectHandle is valid. The length of data storage area can be determined with a call to NormObjectGetSize() for the same objectHandle value.
4.6.12.3. Return Values
This function returns a pointer to the data storage area for the specified transport object. A NULL value may be returned if the object has no associated data content or is not of type NORM_OBJECT_DATA.
4.6.13. NormDataDetachData()
4.6.13.1. Synopsis
#include <normApi.h>
+const char* NormDataAccessData(NormObjectHandle objectHandle);
4.6.12.2. Description
This function allows the application to access the data storage area associated with a transport object of type NORM_OBJECT_DATA. For example, the application may use this function to copy the received data content for its own use. Alternatively, the application may establish "ownership" for the allocated memory space using the NormDataDetachData() function if it is desired to avoid the copy.
If the object specified by the objectHandle parameter has no data content (or is not of type NORM_OBJECT_DATA), a NULL value may be returned. The application MUST NOT attempt to modify the memory space used by NORM_OBJECT_DATA objects during the time an associated objectHandle is valid. The length of data storage area can be determined with a call to NormObjectGetSize() for the same objectHandle value.
4.6.12.3. Return Values
This function returns a pointer to the data storage area for the specified transport object. A NULL value may be returned if the object has no associated data content or is not of type NORM_OBJECT_DATA.
4.6.13. NormDataDetachData()
4.6.13.1. Synopsis
#include <normApi.h>
 
-char* NormDataDetachData(NormObjectHandle objectHandle);
4.6.13.2. Description
This function allows the application to disassociate data storage allocated by the NORM protocol engine for a receive object from the NORM_OBJECT_DATA transport object specified by the objectHandle parameter. It is important that this function is called after the NORM protocol engine has indicated it is finished with the data object (i.e., after a NORM_TX_OBJECT_PURGED, NORM_RX_OBJECT_COMPLETED, or NORM_RX_OBJECT_ABORTED notification event). But the application must call NormDataDetachData() before a call is made to NormObjectCancel() or NormObjectRelease() for the object if it plans to access the data content afterwards. Otherwise, the NORM protocol engine will free the applicable memory space when the associated NORM_OBJECT_DATA transport object is deleted and the application will be unable to access the received data unless it has previously copied the content.
Once the application has used this call to "detach" the data content, it is the application's responsibility to subsequently free the data storage space as needed.
4.6.13.3. Return Values
This function returns a pointer to the data storage area for the specified transport object. A NULL value may be returned if the object has no associated data content or is not of type NORM_OBJECT_DATA.
4.6.14. NormObjectGetSender()
4.6.14.1. Synopsis
#include <normApi.h>
+char* NormDataDetachData(NormObjectHandle objectHandle);
4.6.13.2. Description
This function allows the application to disassociate data storage allocated by the NORM protocol engine for a receive object from the NORM_OBJECT_DATA transport object specified by the objectHandle parameter. It is important that this function is called after the NORM protocol engine has indicated it is finished with the data object (i.e., after a NORM_TX_OBJECT_PURGED, NORM_RX_OBJECT_COMPLETED, or NORM_RX_OBJECT_ABORTED notification event). But the application must call NormDataDetachData() before a call is made to NormObjectCancel() or NormObjectRelease() for the object if it plans to access the data content afterwards. Otherwise, the NORM protocol engine will free the applicable memory space when the associated NORM_OBJECT_DATA transport object is deleted and the application will be unable to access the received data unless it has previously copied the content.
Once the application has used this call to "detach" the data content, it is the application's responsibility to subsequently free the data storage space as needed.
4.6.13.3. Return Values
This function returns a pointer to the data storage area for the specified transport object. A NULL value may be returned if the object has no associated data content or is not of type NORM_OBJECT_DATA.
4.6.14. NormObjectGetSender()
4.6.14.1. Synopsis
#include <normApi.h>
 
-NormNodeHandle NormObjectGetSender(NormObjectHandle objectHandle);
4.6.14.2. Description
This function retrieves the NormNodeHandle corresponding to the remote sender of the transport object associated with the given objectHandle parameter. Note that the returned NormNodeHandle value is only valid for the same period that the objectHandle is valid. The returned NormNodeHandle may optionally be retained for further use by the application using the NormNodeRetain() function call. The returned value can be used in the NORM Node Functions described later in this document.
4.6.14.3. Return Values
This function returns the NormNodeHandle corresponding to the remote sender of the transport object associated with the given objectHandle parameter. A value of NORM_NODE_INVALID is returned if the specified objectHandle references a locally originated, sender object.
4.7. NORM Node Functions
The functions described in this section may be used for NORM sender or receiver (most typically receiver) purposes to retrieve additional information about a remote NormNode, given a valid NormNodeHandle. Note that, unless specifically retained (see NormNodeRetain()), a NormNodeHandle provided in a NormEvent notification should be considered valid only until a subsequent call to NormGetNextEvent() is made. NormNodeHandle values retrieved using NormObjectGetSender() can be considered valid for the same period of time as the corresponding NormObjectHandle is valid.
4.7.1. NormNodeGetId()
4.7.1.1. Synopsis
#include <normApi.h>
+NormNodeHandle NormObjectGetSender(NormObjectHandle objectHandle);
4.6.14.2. Description
This function retrieves the NormNodeHandle corresponding to the remote sender of the transport object associated with the given objectHandle parameter. Note that the returned NormNodeHandle value is only valid for the same period that the objectHandle is valid. The returned NormNodeHandle may optionally be retained for further use by the application using the NormNodeRetain() function call. The returned value can be used in the NORM Node Functions described later in this document.
4.6.14.3. Return Values
This function returns the NormNodeHandle corresponding to the remote sender of the transport object associated with the given objectHandle parameter. A value of NORM_NODE_INVALID is returned if the specified objectHandle references a locally originated, sender object.
4.7. NORM Node Functions
The functions described in this section may be used for NORM sender or receiver (most typically receiver) purposes to retrieve additional information about a remote NormNode, given a valid NormNodeHandle. Note that, unless specifically retained (see NormNodeRetain()), a NormNodeHandle provided in a NormEvent notification should be considered valid only until a subsequent call to NormGetNextEvent() is made. NormNodeHandle values retrieved using NormObjectGetSender() can be considered valid for the same period of time as the corresponding NormObjectHandle is valid.
4.7.1. NormNodeGetId()
4.7.1.1. Synopsis
#include <normApi.h>
 
-NormNodeId NormNodeGetId(NormNodeHandle nodeHandle);
4.7.1.2. Description
This function retrieves the NormNodeId identifier for the remote participant referenced by the given nodeHandle value. The NormNodeId is a 32-bit value used within the NORM protocol to uniquely identify participants within a NORM session. The participants identifiers are assigned by the application or derived (by the NORM API code) from the host computers default IP address.
4.7.1.3. Return Values
This function returns the NormNodeId value associated with the specified nodeHandle. In the case nodeHandle is equal to NORM_NODE_INVALID, the return value will be NORM_NODE_NONE.
4.7.2. NormNodeGetAddress()
4.7.2.1. Synopsis
#include <normApi.h>
+NormNodeId NormNodeGetId(NormNodeHandle nodeHandle);
4.7.1.2. Description
This function retrieves the NormNodeId identifier for the remote participant referenced by the given nodeHandle value. The NormNodeId is a 32-bit value used within the NORM protocol to uniquely identify participants within a NORM session. The participants identifiers are assigned by the application or derived (by the NORM API code) from the host computers default IP address.
4.7.1.3. Return Values
This function returns the NormNodeId value associated with the specified nodeHandle. In the case nodeHandle is equal to NORM_NODE_INVALID, the return value will be NORM_NODE_NONE.
4.7.2. NormNodeGetAddress()
4.7.2.1. Synopsis
#include <normApi.h>
 
 bool NormNodeGetAddress(NormNodeHandle          nodeHandle,
                         char*                   addrBuffer,
                         unsigned int*           bufferLen,
-                        unsigned short*         port = NULL);
4.7.2.2. Description
This function retrieves the current network source address detected for packets received from remote NORM sender referenced by the nodeHandle parameter. The addrBuffer must be a pointer to storage of bufferLen bytes in length in which the referenced sender node's address will be returned. Optionally, the remote sender source port number (see NormSetTxPort()) is also returned if the optional port pointer to storage parameter is provided in the call. Note that in the case of Network Address Translation (NAT) or other firewall activities, the source address detected by the NORM receiver may not be the original address of the original NORM sender.
4.7.2.3. Return Values
A value of true is returned upon success and false upon failure. An invalid nodeHandle parameter value would lead to such failure.
4.7.3. NormNodeGetGrtt()
4.7.3.1. Synopsis
#include <normApi.h>
+                        unsigned short*         port = NULL);
4.7.2.2. Description
This function retrieves the current network source address detected for packets received from remote NORM sender referenced by the nodeHandle parameter. The addrBuffer must be a pointer to storage of bufferLen bytes in length in which the referenced sender node's address will be returned. Optionally, the remote sender source port number (see NormSetTxPort()) is also returned if the optional port pointer to storage parameter is provided in the call. Note that in the case of Network Address Translation (NAT) or other firewall activities, the source address detected by the NORM receiver may not be the original address of the original NORM sender.
4.7.2.3. Return Values
A value of true is returned upon success and false upon failure. An invalid nodeHandle parameter value would lead to such failure.
4.7.3. NormNodeGetGrtt()
4.7.3.1. Synopsis
#include <normApi.h>
 
-double NormNodeGetId(NormNodeHandle nodeHandle);
4.7.3.2. Description
This function retrieves the advertised estimate of group round-trip timing (GRTT) for the remote sender referenced by the given nodeHandle value. Newly-starting senders that have been participating as a receiver within a group may wish to use this function to provide a more accurate startup estimate of GRTT (see NormSetGrttEstimate()) prior to a call to NormStartSender(). Applications may use this information for other purpose as well. Note that the NORM_GRTT_UPDATED event is posted (see NormGetNextEvent()) by the NORM protocol engine to indicate when changes in the local sender or remote senders' GRTT estimate occurs.
4.7.3.3. Return Values
This function returns the remote sender's advertised GRTT estimate in units of seconds. A value of -1.0 is returned upon failure. An invalid nodeHandle parameter value will lead to such failure.
4.7.4. NormNodeGetCommand()
4.7.4.1. Synopsis
#include <normApi.h>
+double NormNodeGetId(NormNodeHandle nodeHandle);
4.7.3.2. Description
This function retrieves the advertised estimate of group round-trip timing (GRTT) for the remote sender referenced by the given nodeHandle value. Newly-starting senders that have been participating as a receiver within a group may wish to use this function to provide a more accurate startup estimate of GRTT (see NormSetGrttEstimate()) prior to a call to NormStartSender(). Applications may use this information for other purpose as well. Note that the NORM_GRTT_UPDATED event is posted (see NormGetNextEvent()) by the NORM protocol engine to indicate when changes in the local sender or remote senders' GRTT estimate occurs.
4.7.3.3. Return Values
This function returns the remote sender's advertised GRTT estimate in units of seconds. A value of -1.0 is returned upon failure. An invalid nodeHandle parameter value will lead to such failure.
4.7.4. NormNodeGetCommand()
4.7.4.1. Synopsis
#include <normApi.h>
 
 bool NormNodeGetCommand(NormNodeHandle nodeHandle,
                         char*          buffer,
-                        unsigned int*  buflen);
4.7.4.2. Description
This function retrieves the content of an application-defined command that was received from a remote sender associated with the given nodeHandle. This call should be made in response to the NORM_RX_CMD_NEW notification. This notification is issued for each command received. However the application may use this call to poll for received commands if desired. Additionally, the received command length can be "queried" by setting the value referenced by the buflen parameter to ZERO. Upon return, this value referenced by the buflen parameter is adjusted to reflect the command length. Then a subsequent call to NormNodeGetCommand() can be made with an appropriately-sized buffer to retrieve the received command content. The command size will be less than or equal to the NORM segment size configured for the given remote sender.
Note that if a rapid succession of commands are sent it is possible that the commands may be delivered to the receivers out-of-order. Also, when repetition is requested (i.e., if robust is set to true) the receiver may receive duplicate copies of the same command. It is up to the application to provide any needed mechanism for detecting and/or filtering duplicate command reception.
4.7.4.3. Return Values
This function returns true upon successful retrieval of command content. A return value of false indicates that either no command was available or the provided buffer size (buflen parameter) was inadequate. The value referenced by the buflen parameter is adjusted to indicate the actual command length (in bytes) upon return.
4.7.5. NormNodeFreeBuffers()
4.7.5.1. Synopsis
#include <normApi.h>
+                        unsigned int*  buflen);
4.7.4.2. Description
This function retrieves the content of an application-defined command that was received from a remote sender associated with the given nodeHandle. This call should be made in response to the NORM_RX_CMD_NEW notification. This notification is issued for each command received. However the application may use this call to poll for received commands if desired. Additionally, the received command length can be "queried" by setting the value referenced by the buflen parameter to ZERO. Upon return, this value referenced by the buflen parameter is adjusted to reflect the command length. Then a subsequent call to NormNodeGetCommand() can be made with an appropriately-sized buffer to retrieve the received command content. The command size will be less than or equal to the NORM segment size configured for the given remote sender.
Note that if a rapid succession of commands are sent it is possible that the commands may be delivered to the receivers out-of-order. Also, when repetition is requested (i.e., if robust is set to true) the receiver may receive duplicate copies of the same command. It is up to the application to provide any needed mechanism for detecting and/or filtering duplicate command reception.
4.7.4.3. Return Values
This function returns true upon successful retrieval of command content. A return value of false indicates that either no command was available or the provided buffer size (buflen parameter) was inadequate. The value referenced by the buflen parameter is adjusted to indicate the actual command length (in bytes) upon return.
4.7.5. NormNodeFreeBuffers()
4.7.5.1. Synopsis
#include <normApi.h>
 
-void NormNodeFreeBuffers(NormNodeHandle nodeHandle);
4.7.5.2. Description
This function releases memory resources that were allocated for a remote sender. For example, the receiver application may wish to free memory resources when receiving a NORM_REMOTE_SENDER_INACTIVE notification for a given remote sender when multiple senders may be providing content. The NORM protocol engine allocates memory for reliable transport buffering on a per sender basis according to the limit set in the NormStartReceiver() call. These buffering resources comprise the majority of the state allocated for a given remote sender. For NORM applications with possibly multiple senders active at different times, this function can be used to manage to amount of memory allocated for reliable reception. If a sender becomes "active" again after a call to NormNodeFreeBuffers(), new memory resources will be allocated. Note that state for any pending (uncompleted) objects will be dropped when this function is called and the receiver may request retransmission and repair of content if the sender once again becomes "active". The application SHOULD call NormObjectCancel() for any pending objects before calling NormNodeFreeBuffers() if it wishes to never receive those pending objects. Alternatively, a call to NormNodeDelete() will completely eliminate all state for a given remote sender and, if that sender becomes "active" again, it will be treated as a completely new sender.
4.7.5.3. Return Values
This function has no return value.
4.7.6. NormNodeDelete()
4.7.6.1. Synopsis
#include <normApi.h>
+void NormNodeFreeBuffers(NormNodeHandle nodeHandle);
4.7.5.2. Description
This function releases memory resources that were allocated for a remote sender. For example, the receiver application may wish to free memory resources when receiving a NORM_REMOTE_SENDER_INACTIVE notification for a given remote sender when multiple senders may be providing content. The NORM protocol engine allocates memory for reliable transport buffering on a per sender basis according to the limit set in the NormStartReceiver() call. These buffering resources comprise the majority of the state allocated for a given remote sender. For NORM applications with possibly multiple senders active at different times, this function can be used to manage to amount of memory allocated for reliable reception. If a sender becomes "active" again after a call to NormNodeFreeBuffers(), new memory resources will be allocated. Note that state for any pending (uncompleted) objects will be dropped when this function is called and the receiver may request retransmission and repair of content if the sender once again becomes "active". The application SHOULD call NormObjectCancel() for any pending objects before calling NormNodeFreeBuffers() if it wishes to never receive those pending objects. Alternatively, a call to NormNodeDelete() will completely eliminate all state for a given remote sender and, if that sender becomes "active" again, it will be treated as a completely new sender.
4.7.5.3. Return Values
This function has no return value.
4.7.6. NormNodeDelete()
4.7.6.1. Synopsis
#include <normApi.h>
 
-void NormNodeDelete(NormNodeHandle nodeHandle);
4.7.6.2. Description
This function can be used by a NORM receiver application to completely remove the state associated with a remote sender for the given nodeHandle. For example, when a NORM_REMOTE_SENDER_INACTIVE notification occurs for a given sender, the application may wish to completely free all associated resources. Note this is distinct from the NormNodeFreeBuffers() call where only the buffering resources are freed and other state pertaining to the sender is kept. If the deleted sender again becomes "active", it will be treated as a brand new sender. Unless explicitly retained with a call to NormNodeRetain(), the nodeHandle should be considered invalid after this call is made. Additionally, any NormObjectHandle values for pending objects from this sender are also invalidated (unless otherwise retained), although NORM_RX_OBJECT_ABORTED notifications may be issued for those pending objects.
4.7.6.3. Return Values
This function has no return value.
4.7.7. NormNodeRetain()
4.7.7.1. Synopsis
#include <normApi.h>
+void NormNodeDelete(NormNodeHandle nodeHandle);
4.7.6.2. Description
This function can be used by a NORM receiver application to completely remove the state associated with a remote sender for the given nodeHandle. For example, when a NORM_REMOTE_SENDER_INACTIVE notification occurs for a given sender, the application may wish to completely free all associated resources. Note this is distinct from the NormNodeFreeBuffers() call where only the buffering resources are freed and other state pertaining to the sender is kept. If the deleted sender again becomes "active", it will be treated as a brand new sender. Unless explicitly retained with a call to NormNodeRetain(), the nodeHandle should be considered invalid after this call is made. Additionally, any NormObjectHandle values for pending objects from this sender are also invalidated (unless otherwise retained), although NORM_RX_OBJECT_ABORTED notifications may be issued for those pending objects.
4.7.6.3. Return Values
This function has no return value.
4.7.7. NormNodeRetain()
4.7.7.1. Synopsis
#include <normApi.h>
 
-void NormNodeRetain(NormNodeHandle nodeHandle);
4.7.7.2. Description
In the same manner as the NormObjectRetain() function, this function allows the application to retain state associated with a given nodeHandle value even when the underlying NORM protocol engine might normally free the associated state and thus invalidate the NormNodeHandle. If the application uses this function, it must make a corresponding call to NormNodeRelease() when finished with the node information to avoid a memory leak condition. NormNodeHandle values (unless retained) are valid from the time of a NORM_REMOTE_SENDER_NEW notification until a complimentary NORM_REMOTE_SENDER_PURGED notification. During that interval, the application will receive NORM_REMOTE_SENDER_ACTIVE and NORM_REMOTE_SENDER_INACTIVE notifications according to the sender's message transmission activity within the session.
It is important to note that, if the NORM protocol engine posts a NORM_REMOTE_SENDER_PURGED notification for a given NormNodeHandle, the NORM protocol engine could possibly, subsequently establish a new, different NormNodeHandle value for the same remote sender (i.e., one of equivalent NormNodeId) if it again becomes active in the session. A new NormNodeHandle may likely be established even if the application has retained the previous NormNodeHandle value. Therefore, to the application, it might appear that two different senders with the same NormNodeId are participating if these notifications are not carefully monitored. This behavior is contingent upon how the application has configured the NORM protocol engine to manage resources when there is potential for a large number of remote senders within a session (related APIs are TBD). For example, the application may wish to control which specific remote senders for which it keeps state (or limit the memory resources used for remote sender state, etc) and the NORM API may be extended in the future to control this behavior.
4.7.7.3. Return Values
This function has no return value.
4.7.8. NormNodeRelease()
4.7.8.1. Synopsis
#include <normApi.h>
+void NormNodeRetain(NormNodeHandle nodeHandle);
4.7.7.2. Description
In the same manner as the NormObjectRetain() function, this function allows the application to retain state associated with a given nodeHandle value even when the underlying NORM protocol engine might normally free the associated state and thus invalidate the NormNodeHandle. If the application uses this function, it must make a corresponding call to NormNodeRelease() when finished with the node information to avoid a memory leak condition. NormNodeHandle values (unless retained) are valid from the time of a NORM_REMOTE_SENDER_NEW notification until a complimentary NORM_REMOTE_SENDER_PURGED notification. During that interval, the application will receive NORM_REMOTE_SENDER_ACTIVE and NORM_REMOTE_SENDER_INACTIVE notifications according to the sender's message transmission activity within the session.
It is important to note that, if the NORM protocol engine posts a NORM_REMOTE_SENDER_PURGED notification for a given NormNodeHandle, the NORM protocol engine could possibly, subsequently establish a new, different NormNodeHandle value for the same remote sender (i.e., one of equivalent NormNodeId) if it again becomes active in the session. A new NormNodeHandle may likely be established even if the application has retained the previous NormNodeHandle value. Therefore, to the application, it might appear that two different senders with the same NormNodeId are participating if these notifications are not carefully monitored. This behavior is contingent upon how the application has configured the NORM protocol engine to manage resources when there is potential for a large number of remote senders within a session (related APIs are TBD). For example, the application may wish to control which specific remote senders for which it keeps state (or limit the memory resources used for remote sender state, etc) and the NORM API may be extended in the future to control this behavior.
4.7.7.3. Return Values
This function has no return value.
4.7.8. NormNodeRelease()
4.7.8.1. Synopsis
#include <normApi.h>
 
-void NormNodeRelease(NormNodeHandle nodeHandle);
4.7.8.2. Description
In complement to the NormNodeRetain() function, this API call releases the specified nodeHandle so that the NORM protocol engine may free associated resources as needed. Once this call is made, the application should no longer reference the specified NormNodeHandle, unless it is still valid.
4.7.8.3. Return Values
This function has no return value.
4.8. NORM Debugging Functions
This section describes some additional function calls that are available to set debugging output options and control other aspects of the NORM implementation.
4.8.1. NormSetDebugLevel()
4.8.1.1. Synopsis
#include <normApi.h>
+void NormNodeRelease(NormNodeHandle nodeHandle);
4.7.8.2. Description
In complement to the NormNodeRetain() function, this API call releases the specified nodeHandle so that the NORM protocol engine may free associated resources as needed. Once this call is made, the application should no longer reference the specified NormNodeHandle, unless it is still valid.
4.7.8.3. Return Values
This function has no return value.
4.8. NORM Debugging Functions
This section describes some additional function calls that are available to set debugging output options and control other aspects of the NORM implementation.
4.8.1. NormSetDebugLevel()
4.8.1.1. Synopsis
#include <normApi.h>
 
-void NormSetDebugLevel(unsigned int level);
4.8.1.2. Description
This function controls the verbosity of NORM debugging output. Higher values of level result in more detailed output. The highest level of debugging is 12. The debug output consists of text written to STDOUT by default but may be directed to a log file using the NormOpenDebugLog() function.
4.8.1.3. Return Values
This function has no return value.
4.8.2. NormOpenDebugLog()
4.8.2.1. Synopsis
#include <normApi.h>
+void NormSetDebugLevel(unsigned int level);
4.8.1.2. Description
This function controls the verbosity of NORM debugging output. Higher values of level result in more detailed output. The highest level of debugging is 12. The debug output consists of text written to STDOUT by default but may be directed to a log file using the NormOpenDebugLog() function.
4.8.1.3. Return Values
This function has no return value.
4.8.2. NormOpenDebugLog()
4.8.2.1. Synopsis
#include <normApi.h>
 
-bool NormOpenDebugLog(NormInstanceHandle instance, const char* fileName);
4.8.2.2. Description
This function allows NORM debug output to be directed to a file instead of the default STDERR.
4.8.2.3. Return Values
The function returns true on success. If the specified file cannot be opened a value of false is returned.
4.8.3. NormCloseDebugLog()
4.8.3.1. Synopsis
#include <normApi.h>
+bool NormOpenDebugLog(NormInstanceHandle instance, const char* fileName);
4.8.2.2. Description
This function allows NORM debug output to be directed to a file instead of the default STDERR.
4.8.2.3. Return Values
The function returns true on success. If the specified file cannot be opened a value of false is returned.
4.8.3. NormCloseDebugLog()
4.8.3.1. Synopsis
#include <normApi.h>
 
-bool NormCloseDebugLog(NormInstanceHandle instance);
4.8.3.2. Description
TBD
4.8.3.3. Return Values
TBD
4.8.4. NormOpenDebugPipe()
4.8.4.1. Synopsis
#include <normApi.h>
+bool NormCloseDebugLog(NormInstanceHandle instance);
4.8.3.2. Description
TBD
4.8.3.3. Return Values
TBD
4.8.4. NormOpenDebugPipe()
4.8.4.1. Synopsis
#include <normApi.h>
 
-bool NormOpenDebugPipe(NormInstanceHandle instance, const char* pipeName);
4.8.4.2. Description
TBD
4.8.4.3. Return Values
TBD
4.8.5. NormCloseDebugPipe()
4.8.5.1. Synopsis
#include <normApi.h>
+bool NormOpenDebugPipe(NormInstanceHandle instance, const char* pipeName);
4.8.4.2. Description
TBD
4.8.4.3. Return Values
TBD
4.8.5. NormCloseDebugPipe()
4.8.5.1. Synopsis
#include <normApi.h>
 
-bool NormCloseDebugPipe(NormInstanceHandle instance);
4.8.5.2. Description
TBD
4.8.5.3. Return Values
TBD
\ No newline at end of file +bool NormCloseDebugPipe(NormInstanceHandle instance);
4.8.5.2. Description

TBD

4.8.5.3. Return Values

TBD

\ No newline at end of file diff --git a/doc/NormDeveloperGuide.pdf b/doc/NormDeveloperGuide.pdf index ac297c4..db614bc 100644 Binary files a/doc/NormDeveloperGuide.pdf and b/doc/NormDeveloperGuide.pdf differ diff --git a/doc/NormDeveloperGuide.xml b/doc/NormDeveloperGuide.xml index 9c7b386..c4b5229 100644 --- a/doc/NormDeveloperGuide.xml +++ b/doc/NormDeveloperGuide.xml @@ -5,9 +5,9 @@ <inlinemediaobject> <imageobject> - <imagedata align="center" fileref="NormLogo.gif" scale="50" /> + <imagedata align="center" fileref="NormLogo.gif" scale="50"/> </imageobject> - </inlinemediaobject> NORM Developer's Guide (version 1.4b4) + NORM Developer's Guide (version 1.5b5) NORM Developer's Guide @@ -1234,9 +1234,9 @@ bool NormGetNextEvent - + - + @@ -1430,8 +1430,8 @@ bool NormGetNextEvent NORM_REMOTE_SENDER_ACTIVE This event is posted when a previously inactive - (or new) remote sender is detected operating as an active + (or new) remote sender is detected operating as an active sender within the session. @@ -1675,9 +1675,9 @@ NormSessionHandle No - + - + @@ -1886,7 +1886,7 @@ const void* NormGetUserData - Return Values + Return Valuess The returned value indicates the NormNode identifier used by the NORM protocol engine for the local @@ -2185,8 +2185,8 @@ NormSetMulticastInterface(session, "interface2");A return value of true indicates success while a return value of false indicates that - the specified interface was valid. This function will always return - true if made before calls to true if made before calls to NormStartSender() or NormStartReceiver(). @@ -2195,6 +2195,50 @@ NormSetMulticastInterface(session, "interface2"); + + NormSetSSM() + + + Synopsis + + #include <normApi.h> + +bool NormSetSSM(NormSessionHandle session, + const char* sourceAddress); + + + + Description + + This function sets the source address for Source-Specific + Multicast (SSM) operation. This should be called + before any call to NormStartSender() + or NormStartReceiver() + is made so that the proper group join is done. The receiver + application MUST also use the NormSetDefaultUnicastNack() + call so that feedback traffic is directed back to appropriate + sender. + + + + Return Values + + A return value of true indicates success + while a return value of false indicates that + the specified source address was invalid. Note that if a valid IP + address is specified but is improper for SSM (e.g., an IP multicast + address) the later calls to NormStartSender() + or NormStartReceiver() + may fail. + + + NormSetTTL() @@ -2352,8 +2396,7 @@ bool NormSetFragmentation + fragmentation disabled) by default on most operating systems. This call is not currently functional on the Mac OSX system that does not support the needed @@ -2371,7 +2414,7 @@ bool NormSetFragmentation - <anchor id="_NORM_Sender_Functions" />NORM Sender + <title><anchor id="_NORM_Sender_Functions"/>NORM Sender Functions The functions described in this section apply only to NORM sender @@ -2412,9 +2455,9 @@ bool NormStartSender(< - + - + diff --git a/examples/normClient.cpp b/examples/normClient.cpp new file mode 100644 index 0000000..9043b2c --- /dev/null +++ b/examples/normClient.cpp @@ -0,0 +1,296 @@ +#include "normSocket.h" +#include +#include +#include +#include // for, well, fnctl() +#include // obvious child + +// BUILD: (assumes "normApi.h" in "include" ... +// g++ -I../include -o normClient normClient.cpp normSocket.cpp ../lib/libnorm.a ../protolib/lib/libprotokit.a -lresolv + + +// NOTES: +// 1) THIS IS A WORK IN PROGRESS AND NOT YET FUNCTIONAL! +// 2) Some of the functions here may be added to the NORM API in the future. + +// Client initiates connection to "server". When the "client" gets a NORM_REMOTE_SENDER_NEW +// from the "server", it knows its connection has been accepted. + +// To deny a connection, the "server" can send a stream close??? Which means the server will have +// to establish state just to deny a client a connection (yuck!) + +const unsigned int MSG_LENGTH_MAX = 64; + +int main(int argc, char* argv[]) +{ + char serverAddr[64]; + strcpy(serverAddr, "127.0.0.1"); + UINT16 serverPort = 5000; + char groupAddr[64]; + const char* groupAddrPtr = NULL; + const char* mcastInterface = NULL; + NormNodeId clientId = 2; + bool trace = false; + unsigned int debugLevel = 0; + + for (int i = 1; i < argc; i++) + { + const char* cmd = argv[i]; + unsigned int len = strlen(cmd); + if (0 == strncmp(cmd, "connect", len)) + { + // connect /[, + const char* val = argv[++i]; + const char* portPtr = strchr(val, '/'); + if (NULL == portPtr) + { + fprintf(stderr, "normClient error: missing number\n"); + return -1; + } + portPtr++; + unsigned int addrTextLen = portPtr - val; + if (addrTextLen > 0) + { + addrTextLen -= 1; + strncpy(serverAddr, val, addrTextLen); + serverAddr[addrTextLen] = '\0'; + } + else + { + fprintf(stderr, "normClient error: missing \n"); + return -1; + } + char portText[32]; + const char* groupPtr = strchr(portPtr, ','); + if (NULL == groupPtr) + { + strcpy(portText, portPtr); + } + else + { + groupPtr++; + unsigned int portTextLen = groupPtr - portPtr - 1; + strncpy(portText, portPtr, portTextLen); + portText[portTextLen] = '\0'; + } + if (1 != sscanf(portText, "%hu", &serverPort)) + { + fprintf(stderr, "normClient error: invalid \n"); + return -1; + } + if (NULL != groupPtr) + { + strcpy(groupAddr, groupPtr); + groupAddrPtr = groupAddr; + } + } + else if (0 == strncmp(cmd, "interface", len)) + { + mcastInterface = argv[++i]; + } + else if (0 == strncmp(cmd, "trace", len)) + { + trace = true; + } + else if (0 == strncmp(cmd, "debug", len)) + { + if (1 != sscanf(argv[++i], "%u", &debugLevel)) + { + fprintf(stderr, "normServer error: invalid debug level\n"); + return -1; + } + } + else if (0 == strncmp(cmd, "id", len)) + { + const char* val = argv[++i]; + unsigned long id; + if (1 != sscanf(val, "%lu", &id)) + { + fprintf(stderr, "normClient error: invalid 'id' value\n"); + return -1; + } + clientId = id; + } + else + { + fprintf(stderr, "normServer error: invalid command \"%s\"\n", cmd); + return -1; + } + } + + NormInstanceHandle instance = NormCreateInstance(); + + // Initate connection to server ... + fprintf(stderr, "normClient: connecting to %s/%hu ...\n", serverAddr, serverPort); + NormSocketHandle normSocket = NormConnect(instance, serverAddr, serverPort, groupAddrPtr, clientId); + + if (trace) + { + NormSetMessageTrace(NormGetSession(normSocket), true); + if (NULL != groupAddrPtr) + NormSetMessageTrace(NormGetMulticastSession(normSocket), true); + } + if (0 != debugLevel) NormSetDebugLevel(debugLevel); + + //NormSetDebugLevel(3); + //NormSetMessageTrace(NormGetSession(normSocket), true); + + // We use a select() call to multiplex input reading and NormSocket handling + fd_set fdset; + FD_ZERO(&fdset); + + // Get our input (STDIN) descriptor and set non-blocking + FILE* inputFile = stdin; + int inputfd = fileno(inputFile); + if (-1 == fcntl(inputfd, F_SETFL, fcntl(inputfd, F_GETFL, 0) | O_NONBLOCK)) + perror("normClient: fcntl(inputfd, O_NONBLOCK) error"); + // Get our NormInstance descriptor + int normfd = NormGetDescriptor(instance); + bool keepGoing = true; + bool writeReady = false; + unsigned int inputLength = 0; + unsigned int bytesWritten = 0; + const unsigned int BUFFER_LENGTH = 2048; + char inputBuffer[BUFFER_LENGTH]; + bool inputNeeded = false; // will be set to "true" upon CONNECT + while (keepGoing) + { + FD_SET(normfd, &fdset); + int maxfd = normfd; + if (inputNeeded) + { + FD_SET(inputfd, &fdset); + if (inputfd > maxfd) maxfd = inputfd; + } + else + { + FD_CLR(inputfd, &fdset); + } + int result = select(maxfd+1, &fdset, NULL, NULL, NULL); + if (result <= 0) + { + perror("normClient: select() error"); + break; + } + if (FD_ISSET(inputfd, &fdset)) + { + // Read input into our txBuffer + inputLength = fread(inputBuffer, 1, BUFFER_LENGTH, inputFile); + if (inputLength > 0) + { + // We got our input + bytesWritten = 0; + inputNeeded = false; + } + else if (feof(inputFile)) + { + // TBD - initiate client shutdown + if (NULL == groupAddrPtr) + { + fprintf(stderr, "normClient: CLOSING connection to server ...\n"); + NormShutdown(normSocket); + } + inputNeeded = false; // TBD -should we also fclose(inputFile)??? + + // else stick around to receive stuff from the server + } + else if (ferror(inputFile)) + { + switch (errno) + { + case EINTR: + // interupted, try again + break; + case EAGAIN: + // input starved, wait for next notification + break; + default: + perror("normClient: error reading input"); + break; + } + } + } + if (FD_ISSET(normfd, &fdset)) + { + + // There's a NORM event pending + NormSocketEvent event; + if (NormGetSocketEvent(instance, &event)) + { + switch (event.type) + { + case NORM_SOCKET_ACCEPT: + // shouldn't happen + break; + + case NORM_SOCKET_CONNECT: + { + fprintf(stderr, "normClient: CONNECTED to server ...\n"); + inputNeeded = true; + writeReady = true; + break; + } + case NORM_SOCKET_READ: + { + // This is a cue to try to read data from stream + // For our test app here, the data is read and output to STDOUT + bool rxReady = true; + while (rxReady) + { + char buffer[1024]; + ssize_t bytesRead = NormRead(event.socket, buffer, 1024); + if (bytesRead < 0) + { + // This shouldn't happen with ack-based flow control used + fprintf(stderr, "normClient: broken stream ...\n"); + continue; + } + if (bytesRead > 0) + fwrite(buffer, sizeof(char), bytesRead, stdout); + if (bytesRead < 1024) rxReady = false; + } + break; + } + case NORM_SOCKET_WRITE: + writeReady = true; + break; + case NORM_SOCKET_CLOSING: + fprintf(stderr, "normClient: server CLOSING connection ...\n"); + inputNeeded = false; + break; + case NORM_SOCKET_CLOSED: + { + fprintf(stderr, "normClient: connection to server CLOSED.\n"); + inputNeeded = false; + keepGoing = false; + break; + } + case NORM_SOCKET_NONE: + break; + } // end switch(event.type) + } + else + { + fprintf(stderr, "normClient: NormGetSocketEvent() returned false\n"); + } + } // end if FD_ISSET(normfd) + + // If we have data in our inputBuffer and the NormSocket is "writeReady", then send it + if (writeReady && (inputLength > 0)) + { + bytesWritten += NormWrite(normSocket, inputBuffer + bytesWritten, inputLength - bytesWritten); + if (bytesWritten < inputLength) + { + // Couldn't write whole inputBuffer, need to wait for NORM_SOCKET_WRITE event + writeReady = false; + } + else + { + // inputBuffer has been completely written + inputLength = 0; + inputNeeded = true; + NormFlush(normSocket); + } + } + } // end while(keepGoing) +} diff --git a/examples/normMsgr.cpp b/examples/normMsgr.cpp index 1ba8017..b1a6a24 100644 --- a/examples/normMsgr.cpp +++ b/examples/normMsgr.cpp @@ -1,6 +1,8 @@ #include "normApi.h" +#include "protoCheck.h" + #include // for printf(), etc #include // for srand() #include // for strrchr(), memset(), etc @@ -49,8 +51,8 @@ class NormMsgr char* AccessBuffer() {return msg_buffer;} - void ResetIndex() - {msg_index = 0;} + void ResetIndex(unsigned int index = 0) + {msg_index = index;} void IncrementIndex(unsigned int count) {msg_index += count;} unsigned int GetIndex() const @@ -150,6 +152,15 @@ class NormMsgr bool OutputPending() const {return output_pending;} bool WriteOutput(); + + void OmitHeader(bool state) + {omit_header = state;} + + // These can only be called post-OpenNormSession + void SetSilentReceiver(bool state) + {NormSetSilentReceiver(norm_session, true);} + void SetTxLoss(double txloss) + {NormSetTxLoss(norm_session, txloss);} private: bool is_running; @@ -159,6 +170,7 @@ class NormMsgr MessageQueue input_msg_list; // list of enqueued messages (in norm sender cache) NormSessionHandle norm_session; + bool is_multicast; unsigned int norm_tx_queue_max; // max number of objects that can be enqueued at once unsigned int norm_tx_queue_count; // count of unacknowledged enqueued objects (TBD - optionally track size too) bool norm_tx_watermark_pending; @@ -170,14 +182,19 @@ class NormMsgr bool output_pending; Message* output_msg; MessageQueue output_msg_queue; + // These are some options mainly for testing purposes + bool omit_header; // if "true", receive message length header is _not_ written to output + bool rx_silent; + double tx_loss; }; // end class NormMsgr NormMsgr::NormMsgr() - : input_file(stdin), input_needed(true), input_msg(NULL), - norm_session(NORM_SESSION_INVALID), norm_tx_queue_max(2048), norm_tx_queue_count(0), + : input_file(stdin), input_needed(false), input_msg(NULL), + norm_session(NORM_SESSION_INVALID), is_multicast(false), norm_tx_queue_max(2048), norm_tx_queue_count(0), norm_tx_watermark_pending(false), norm_tx_vacancy(true), norm_acking(false), - output_file(stdout), output_ready(true), output_pending(false), output_msg(NULL) + output_file(stdout), output_ready(true), output_pending(false), output_msg(NULL), + omit_header(false), rx_silent(false), tx_loss(0.0) { } @@ -191,12 +208,25 @@ NormMsgr::~NormMsgr() bool NormMsgr::OpenNormSession(NormInstanceHandle instance, const char* addr, unsigned short port, NormNodeId nodeId) { + if (NormIsUnicastAddress(addr)) + is_multicast = false; + else + is_multicast = true; norm_session = NormCreateSession(instance, addr, port, nodeId); if (NORM_SESSION_INVALID == norm_session) { fprintf(stderr, "normMsgr error: unable to create NORM session\n"); return false; } + + if (is_multicast) + { + NormSetRxPortReuse(norm_session, true); + // TBD - make full loopback a command line option? + NormSetMulticastLoopback(norm_session, true); + } + + // Set some default parameters (maybe we should put parameter setting in Start()) NormSetRxCacheLimit(norm_session, norm_tx_queue_max); NormSetDefaultSyncPolicy(norm_session, NORM_SYNC_ALL); @@ -205,6 +235,9 @@ bool NormMsgr::OpenNormSession(NormInstanceHandle instance, const char* addr, un NormSetTxCacheBounds(norm_session, 10*1024*1024, norm_tx_queue_max, norm_tx_queue_max); //NormSetMessageTrace(norm_session, true); + + NormSetTxRobustFactor(norm_session, 2); + return true; } // end NormMsgr::OpenNormSession() @@ -268,6 +301,7 @@ bool NormMsgr::Start(bool sender, bool receiver) if (receiver) NormStopReceiver(norm_session); return false; } + input_needed = true; } is_running = true; return true; @@ -379,6 +413,7 @@ bool NormMsgr::WriteOutput() bufferPtr = output_msg->GetBuffer() + offset; } size_t result = fwrite(bufferPtr, 1, writeLength, output_file); + output_msg->IncrementIndex(result); if (result < writeLength) { @@ -389,6 +424,7 @@ bool NormMsgr::WriteOutput() } else if (ferror(input_file)) { + fprintf(stderr, "normMsgr: output error detected ...\n"); switch (errno) { case EINTR: @@ -406,12 +442,20 @@ bool NormMsgr::WriteOutput() } if (output_msg->IsComplete()) { + fflush(output_file); delete output_msg; output_msg = output_msg_queue.RemoveHead(); if (NULL != output_msg) - output_msg->ResetIndex(); + { + if (omit_header) + output_msg->ResetIndex(MSG_HEADER_SIZE); + else + output_msg->ResetIndex(); + } else + { output_pending = false; + } break; } } @@ -490,6 +534,7 @@ bool NormMsgr::EnqueueMessageObject() void NormMsgr::HandleNormEvent(const NormEvent& event) { + bool logAllocs = false; switch (event.type) { case NORM_TX_QUEUE_EMPTY: @@ -528,6 +573,18 @@ void NormMsgr::HandleNormEvent(const NormEvent& event) } break; } + + case NORM_REMOTE_SENDER_INACTIVE: + //fprintf(stderr, "REMOTE SENDER INACTIVE node: %u\n", NormNodeGetId(event.sender)); + //NormNodeDelete(event.sender); + //logAllocs = true; + break; + + case NORM_RX_OBJECT_ABORTED: + //fprintf(stderr, "NORM_RX_OBJECT_ABORTED\n");// %hu\n", NormObjectGetTransportId(event.object)); + logAllocs = true; + break; + case NORM_RX_OBJECT_COMPLETED: { char* data = NormDataDetachData(event.object); @@ -536,7 +593,7 @@ void NormMsgr::HandleNormEvent(const NormEvent& event) Message* msg = new Message(data, NormObjectGetSize(event.object)); if (NULL == msg) { - perror("normMsgr new receive Message error"); + perror("normMsgr: new Message() error"); delete[] data; // TBD - may need to finally implement NormDelete() function! // TBD Stop() as a fatal out of memory error? break; @@ -544,7 +601,10 @@ void NormMsgr::HandleNormEvent(const NormEvent& event) if (NULL == output_msg) { output_msg = msg; - output_msg->ResetIndex(); + if (omit_header) + output_msg->ResetIndex(MSG_HEADER_SIZE); + else + output_msg->ResetIndex(); output_pending = true; } else @@ -559,13 +619,23 @@ void NormMsgr::HandleNormEvent(const NormEvent& event) default: break; } + //NormReleasePreviousEvent(NormGetInstance(norm_session)); + + if (logAllocs) + { +#ifdef USE_PROTO_CHECK + ProtoCheckLogAllocations(stderr); +#endif // USE_PROTO_CHECK + } + } // end NormMsgr::HandleNormEvent() void Usage() { fprintf(stderr, "Usage: normMsgr id {send &| recv} [addr [/]][ack [,,...]\n" - " [cc|cce|ccl|rate ][interface ][debug ][trace]\n"); + " [cc|cce|ccl|rate ][interface ][debug ][trace]\n" + " [omit][silent][txloss ]\n"); } int main(int argc, char* argv[]) { @@ -587,6 +657,9 @@ int main(int argc, char* argv[]) int debugLevel = 0; bool trace = false; + bool omitHeaderOnOutput = false; + bool silentReceiver = false; + double txloss = 0.0; // Parse command-line int i = 1; @@ -700,6 +773,23 @@ int main(int argc, char* argv[]) } mcastIface = argv[i++]; } + else if (0 == strncmp(cmd, "omit", len)) + { + omitHeaderOnOutput = true; + } + else if (0 == strncmp(cmd, "silent", len)) + { + silentReceiver = true; + } + else if (0 == strncmp(cmd, "txloss", len)) + { + if (1 != sscanf(argv[i++], "%lf", &txloss)) + { + fprintf(stderr, "nodeMsgr error: invalid 'txloss' value!\n"); + Usage(); + return -1; + } + } else if (0 == strncmp(cmd, "debug", len)) { if (i >= argc) @@ -746,6 +836,8 @@ int main(int argc, char* argv[]) NormMsgr normMsgr; + if (omitHeaderOnOutput) normMsgr.OmitHeader(true); + if (!normMsgr.OpenNormSession(normInstance, sessionAddr, sessionPort, (NormNodeId)nodeId)) { fprintf(stderr, "normMsgr error: unable to open NORM session\n"); @@ -753,6 +845,10 @@ int main(int argc, char* argv[]) return false; } + + if (silentReceiver) normMsgr.SetSilentReceiver(true); + if (txloss > 0.0) normMsgr.SetTxLoss(txloss); + for (unsigned int i = 0; i < ackingNodeCount; i++) normMsgr.AddAckingNode(ackingNodeList[i]); @@ -848,6 +944,9 @@ int main(int argc, char* argv[]) normMsgr.WriteOutput(); // TBD - implement output async i/o notification as needed } // end while(normMsgr.IsRunning() + + fprintf(stderr, "normMsgr exiting ...\n"); + NormDestroyInstance(normInstance); } // end main() @@ -865,6 +964,8 @@ NormMsgr::Message::Message(char* buffer, unsigned int size) uint16_t msgSize = size + MSG_HEADER_SIZE; msgSize = htons(msgSize); memcpy(msg_header, &msgSize, MSG_HEADER_SIZE); + + fprintf(stderr, "output msg ctor data = %.20s\n", buffer); } NormMsgr::Message::~Message() diff --git a/examples/normServer.cpp b/examples/normServer.cpp new file mode 100644 index 0000000..cca42c8 --- /dev/null +++ b/examples/normServer.cpp @@ -0,0 +1,463 @@ + +// This example NORM application acts as unicast "server". A NORM receive-only session "listens" +// on a "serverPort". When new remote senders are detected, the sender is assigned to a +// newly create "client" NormSession that is "connected" to the remote sender/client addr/port. +// The NormSetRxPortReuse() call provides an option to "connect" the underlying NORM UDP socket +// to the remote sender/client address/port. Note this is not yet supported for NORM-CCE (ECN) +// congestion control operation. + +// By creating "client" NormSessions for each client connection, this enables multiple clients +// from the same host (with the same NormNodeId to connect to the server at the same time. +// Otherwise, clients with the same NormNodeId would "collide" at the server receive session. +// Even the approach here is not perfect as a packet from a another client instance with the +// same NormNodeId might change the given "remote sender" source addr/port before the +// connected "client" session is created as a sort of race condition. +// A potential enhancement to NORM would be to allow tracking of multiple remote senders +// with the same NormNodeId but different instanceIds ... + +// BUILD: (assumes "normApi.h" in "include" ... +// g++ -I../include -o normServer normServer.cpp normSocket.cpp ../lib/libnorm.a ../protolib/lib/libprotokit.a -lresolv + + +// EXAMPLE NOTES: +// +// 0) THIS IS A WORK IN PROGRESS AND NOT YET FUNCTIONAL! +// +// 1) Some of the functions here may be added to the NORM API in the future. +// +// 2) The "main()" below is a single-threaded example with a single NormInstance and a +// single NormGetNextEvent() main loop. Note that the NormAccept() call allows for a +// new instance (and hence new NormDescriptor) for each accepted client, so multiple +// threads or event thread-pooling versions of this could be implemented for +// performance or application design purposes. A future version of the NORM API and +// this could even provide for very "socket-like" API calls where each "client" +// session has its own descriptor independent of threading (e.g. a "normSocket.h" API +// that is implemented around the current low level NORM API). This sort of "NORM +// socket" approach could be supported for unicast and SSM streams without too much +// difficulty. + +#include "normSocket.h" +#include // for inet_ntoa +#include // for fprintf() +#include // for memcmp() +#include // for std::map<> +#include +#include // for, well, fnctl() +#include // obvious child + +// Our "server" indexes clients by their source addr/port +class ClientInfo +{ + public: + ClientInfo(UINT8 ipVersion = 0, const char* theAddr = NULL, UINT16 thePort = 0); + bool operator < (const ClientInfo& a) const; + + int GetAddressFamily() const; + const char* GetAddress() const + {return client_addr;} + UINT16 GetPort() const + {return client_port;} + + const char* GetAddressString() const; + void Print(FILE* filePtr) const; + + private: + UINT8 addr_version; // 4 or 6 + char client_addr[16]; // big enough for IPv6 + UINT16 client_port; + +}; // end class ClientInfo + + +ClientInfo::ClientInfo(UINT8 addrVersion, const char* clientAddr, UINT16 clientPort) + : addr_version(addrVersion), client_port(clientPort) +{ + if (NULL == clientAddr) addrVersion = 0; // forces zero initialization + switch (addrVersion) + { + case 4: + memcpy(client_addr, clientAddr, 4); + memset(client_addr+4, 0, 12); + break; + case 6: + memcpy(client_addr, clientAddr, 16); + break; + default: + memset(client_addr, 0, 16); + break; + } +} + +// returns "true" if "this" less than "a" (used by C++ map) +bool ClientInfo::operator <(const ClientInfo& a) const +{ + if (addr_version != a.addr_version) + return (addr_version < a.addr_version); + else if (client_port != a.client_port) + return (client_port < a.client_port); + else if (4 == addr_version) + return (0 > memcmp(client_addr, a.client_addr, 4)); + else + return (0 > memcmp(client_addr, a.client_addr, 16)); +} // end ClientInfo::operator <() + +int ClientInfo::GetAddressFamily() const +{ + if (4 == addr_version) + return AF_INET; + else + return AF_INET6; +} // end ClientInfo::GetAddressFamily() + + +const char* ClientInfo::GetAddressString() const +{ + static char text[64]; + text[63] = '\0'; + int addrFamily; + if (4 == addr_version) + addrFamily = AF_INET; + else + addrFamily = AF_INET6; + inet_ntop(addrFamily, client_addr, text, 63); + return text; +} // end ClientInfo::GetAddressString() + +void ClientInfo::Print(FILE* filePtr) const +{ + char text[64]; + text[63] = '\0'; + int addrFamily; + if (4 == addr_version) + addrFamily = AF_INET; + else + addrFamily = AF_INET6; + inet_ntop(addrFamily, client_addr, text, 63); + fprintf(filePtr, "%s/%hu", text, client_port); +} // end ClientInfo::Print() + + +// C++ map used to index client sessions by the client source addr/port +typedef std::map ClientMap; + +ClientInfo NormGetClientInfo(NormNodeHandle client) +{ + char addr[16]; // big enough for IPv6 + unsigned int addrLen = 16; + UINT16 port; + NormNodeGetAddress(client, addr, &addrLen, &port); + int addrFamily; + UINT8 version; + if (4 == addrLen) + { + addrFamily = AF_INET; + version = 4; + } + else + { + addrFamily = AF_INET6; + version = 6; + } + return ClientInfo(version, addr, port); +} // end NormGetClientInfo() + +NormSocketHandle FindClientSocket(ClientMap& clientMap, const ClientInfo& clientInfo) +{ + ClientMap::iterator it = clientMap.find(clientInfo); + if (clientMap.end() != it) + return &(it->second); + else + return NORM_SOCKET_INVALID; +} // end FindClientSocket() + + + +int main(int argc, char* argv[]) +{ + ClientMap clientMap; + + UINT16 serverPort = 5000; + UINT16 serverInstanceId = 1; + char groupAddr[64]; + const char* groupAddrPtr = NULL; + const char* mcastInterface = NULL; + + bool trace = false; + unsigned int debugLevel = 0; + + + for (int i = 1; i < argc; i++) + { + const char* cmd = argv[i]; + unsigned int len = strlen(cmd); + if (0 == strncmp(cmd, "listen", len)) + { + // listen [/] + const char* val = argv[++i]; + const char* portPtr = strchr(val, '/'); + if (NULL != portPtr) + portPtr++; + else + portPtr = val; + unsigned int addrTextLen = portPtr - val; + if (addrTextLen > 0) + { + addrTextLen -= 1; + strncpy(groupAddr, val, addrTextLen); + groupAddr[addrTextLen] = '\0'; + groupAddrPtr = groupAddr; + } + if (1 != sscanf(portPtr, "%hu", &serverPort)) + { + fprintf(stderr, "normServer error: invalid \"%s\"\n", portPtr); + return -1; + } + } + else if (0 == strncmp(cmd, "interface", len)) + { + mcastInterface = argv[++i]; + } + else if (0 == strncmp(cmd, "trace", len)) + { + trace = true; + } + else if (0 == strncmp(cmd, "debug", len)) + { + if (1 != sscanf(argv[++i], "%u", &debugLevel)) + { + fprintf(stderr, "normServer error: invalid debug level\n"); + return -1; + } + } + else + { + fprintf(stderr, "normServer error: invalid command \"%s\"\n", cmd); + return -1; + } + } + + // For unicast operation in this demo app, the server only "talks back" + // to one client on a first come, first serve basis. (Multiple clients + // can connect and send data _to_ the server, but in this simple example, + // the server only sends to one at a time. For the multicast server case, + // the server multicasts to the entire group. + NormSocketHandle firstClientSocket = NORM_SOCKET_INVALID; + + NormInstanceHandle instance = NormCreateInstance(); + + NormSocketHandle serverSocket = NormListen(instance, serverPort, groupAddrPtr); + + if (trace) NormSetMessageTrace(NormGetSession(serverSocket), true); + if (0 != debugLevel) NormSetDebugLevel(debugLevel); + + //NormSetDebugLevel(8); + //NormSetMessageTrace(NormGetSession(serverSocket), true); + + // We use a select() call to multiplex input reading and NormSocket handling + fd_set fdset; + FD_ZERO(&fdset); + + // Get our input (STDIN) descriptor and set non-blocking + FILE* inputFile = stdin; + int inputfd = fileno(inputFile); + if (-1 == fcntl(inputfd, F_SETFL, fcntl(inputfd, F_GETFL, 0) | O_NONBLOCK)) + perror("normClient: fcntl(inputfd, O_NONBLOCK) error"); + // Get our NormInstance descriptor + int normfd = NormGetDescriptor(instance); + bool keepGoing = true; + bool writeReady = false; + unsigned int inputLength = 0; + unsigned int bytesWritten = 0; + const unsigned int BUFFER_LENGTH = 2048; + char inputBuffer[BUFFER_LENGTH]; + bool inputNeeded = false; // will be set to "true" upon CONNECT + while (keepGoing) + { + FD_SET(normfd, &fdset); + int maxfd = normfd; + if (inputNeeded) + { + FD_SET(inputfd, &fdset); + if (inputfd > maxfd) maxfd = inputfd; + } + else + { + FD_CLR(inputfd, &fdset); + } + int result = select(maxfd+1, &fdset, NULL, NULL, NULL); + if (result <= 0) + { + perror("normClient: select() error"); + break; + } + if (FD_ISSET(inputfd, &fdset)) + { + // Read input into our txBuffer + inputLength = fread(inputBuffer, 1, BUFFER_LENGTH, inputFile); + if (inputLength > 0) + { + // We got our input + bytesWritten = 0; + inputNeeded = false; + } + else if (feof(inputFile)) + { + // TBD - initiate server shutdown if it's job is + // only until the input is closed + // Meanwhile, we just stick around to receive stuff from the clients + inputNeeded = false; // TBD - should also fclose(inputFile)?? + } + else if (ferror(inputFile)) + { + switch (errno) + { + case EINTR: + // interupted, try again + break; + case EAGAIN: + // input starved, wait for next notification + break; + default: + perror("normClient: error reading input"); + break; + } + } + } + if (FD_ISSET(normfd, &fdset)) + { + + // There's a NORM event pending + NormSocketEvent event; + if (NormGetSocketEvent(instance, &event)) + { + ClientInfo clientInfo; + if (NORM_NODE_INVALID != event.sender) + clientInfo = NormGetClientInfo(event.sender); + switch (event.type) + { + case NORM_SOCKET_ACCEPT: + { + if (event.socket == serverSocket) + { + // Possibly a new "client" connecting to our "server" + // First confirm that this really is a new client. + if (NORM_SOCKET_INVALID != FindClientSocket(clientMap, clientInfo)) + { + // We think we're already connected to this client + fprintf(stderr, "normServer: duplicative %s client ...\n", + (NORM_REMOTE_SENDER_NEW == event.event.type) ? "new" : "reset"); + continue; + } + NormSocketHandle clientSocket = NormAccept(serverSocket, event.sender); + + // TBD - For multicast, if we are sending a tx_stream, we could flush it here to + // bring the new receiver "up to date" ... probably would be best to + // do this on some sort of timer-basis in the case of a bunch of receivers + // joining in a short window of time ... + + if (trace) // note we're already tracing the mcast session + NormSetMessageTrace(NormGetSession(clientSocket), true); + //NormSetMessageTrace(NormGetSession(clientSocket), true); + clientMap[clientInfo] = clientSocket; + fprintf(stderr, "normServer: ACCEPTED connection from %s/%hu\n", + clientInfo.GetAddressString(), clientInfo.GetPort()); + // We have at least one client, so lets serve up some juicy input + inputNeeded = true; + writeReady = true; + } + else + { + // shouldn't happen + } + break; + } + case NORM_SOCKET_CONNECT: + { + fprintf(stderr, "normServer: CONNECTED to %s/%hu ...\n", + clientInfo.GetAddressString(), clientInfo.GetPort()); + if (NORM_SOCKET_INVALID == firstClientSocket) + firstClientSocket = event.socket; + break; + } + case NORM_SOCKET_READ: + { + // This is a cue to try to read data from stream + // For our test app here, the data is read and output to STDOUT + bool rxReady = true; + while (rxReady) + { + char buffer[1024]; + ssize_t bytesRead = NormRead(event.socket, buffer, 1024); + if (bytesRead < 0) + { + // This shouldn't happen with ack-based flow control used + fprintf(stderr, "normServer: broken stream ...\n"); + continue; + } + if (bytesRead > 0) + fwrite(buffer, sizeof(char), bytesRead, stdout); + if (bytesRead < 1024) rxReady = false; + } + break; + } + case NORM_SOCKET_WRITE: + // We only demo server data transmission for the multicast server case + // (see comment below) + if ((NULL != groupAddrPtr) || (event.socket == firstClientSocket)) + writeReady = true; + break; + case NORM_SOCKET_CLOSING: + fprintf(stderr, "normServer: client %s/%hu CLOSING connection ...\n", + clientInfo.GetAddressString(), clientInfo.GetPort()); + if (event.socket == firstClientSocket) + firstClientSocket = NORM_SOCKET_INVALID; + + break; + case NORM_SOCKET_CLOSED: + { + fprintf(stderr, "normServer: connection to client %s/%hu CLOSED ...\n", + clientInfo.GetAddressString(), clientInfo.GetPort()); + if (event.socket == firstClientSocket) + firstClientSocket = NORM_SOCKET_INVALID; + clientMap.erase(clientInfo); + break; + } + case NORM_SOCKET_NONE: + break; + break; + } // end switch(event.type) + } + else + { + fprintf(stderr, "normServer: NormGetNextSocketEvent() returned false\n"); + } + } // end if FD_ISSET(normfd) + + // For our _multicast_ "normServer" example, the server can send to the group + // (For a unicast "normServer", we would need to do something more complex + // to manage sending data to each individual client that connects to us. + // So, for the moment, the unicast "normServer" only sends to the "firstClientSocket" + NormSocketHandle sendSocket = (NULL != groupAddrPtr) ? serverSocket : firstClientSocket; + if (NORM_SOCKET_INVALID != sendSocket) + { + if (writeReady && (inputLength > 0)) + { + // We have data in our inputBuffer and the NormSocket is "writeReady", so send it + bytesWritten += NormWrite(sendSocket, inputBuffer + bytesWritten, inputLength - bytesWritten); + if (bytesWritten < inputLength) + { + // Couldn't write whole inputBuffer, need to wait for NORM_SOCKET_WRITE event + writeReady = false; + } + else + { + // inputBuffer has been completely written + inputLength = 0; + inputNeeded = true; + NormFlush(sendSocket); + } + } + } + + } // end while (keepGoing) +} // end main() diff --git a/examples/normSocket.cpp b/examples/normSocket.cpp new file mode 100644 index 0000000..5b1a35f --- /dev/null +++ b/examples/normSocket.cpp @@ -0,0 +1,1037 @@ + +#include "normSocket.h" +#include // for stderr +#include // for assert() +#include // for strlen() +#include // for inet_ntoa() (TBD - change to use Protolib routines?) + +// COMPILE: (assumes "normApi.h" in "include" ... +// g++ -I../include -c normSocket.cpp + + +// This "NormSocket" class is used to maintain tx/rx state for a NORM "socket" connection. +// At the moment this "socket" connection represents a single, bi-directional NORM_OBJECT_STREAM +// in either a unicast context or an asymmetric "server" multicast stream to possibly multiple "client" +// nodes with individual unicast streams in return from those "client" nodes. (I.e., the server will need to +// have a normSocket per client even for the server multicast case (maybe :-) ) + +const NormSocketHandle NORM_SOCKET_INVALID = (NormSocketHandle)0; + +const double NORM_DEFAULT_CONNECT_TIMEOUT = 60.0; + +// a 'helper' function we use for debugging +const char* NormNodeGetAddressString(NormNodeHandle node) +{ + char addr[16]; // big enough for IPv6 + unsigned int addrLen = 16; + UINT16 port; + if (NormNodeGetAddress(node, addr, &addrLen, &port)) + { + static char text[64]; + text[0] = text[31] = '\0'; + int addrFamily; + if (4 == addrLen) + addrFamily = AF_INET; + else + addrFamily = AF_INET6; + inet_ntop(addrFamily, addr, text, 31); + sprintf(text + strlen(text), "/%hu", port); + return text; + } + else + { + return "???"; + } +} // end NormNodeGetAddressString() + +class NormSocket +{ + public: + NormSocket(NormSessionHandle normSession = NORM_SESSION_INVALID); + + // These methods identify the role of this socket with respect + // to the client / server relationship (a "server socket" is + // one for which NormListen() has been invoked). + bool IsServerSocket() const + {return (server_socket == this);} + bool IsClientSocket() const + {return (server_socket != this);} + bool IsUnicastSocket() const + {return (NORM_SESSION_INVALID == mcast_session);} + bool IsMulticastSocket() const + {return !IsUnicastSocket();} + bool IsMulticastServer() const + {return (IsMulticastSocket() && IsServerSocket());} + bool IsMulticastClient() const + {return (IsMulticastSocket() && IsClientSocket());} + bool IsServerSide() const + {return (NULL != server_socket);} + bool IsClientSide() const + {return (NULL == server_socket);} + + NormSessionHandle GetSession() const + {return norm_session;} + NormSessionHandle GetMulticastSession() const + {return mcast_session;} + + void InitRxStream(NormObjectHandle rxStream) + {rx_stream = rxStream;} + NormObjectHandle GetRxStream() const + {return rx_stream;} + + void InitTxStream(NormObjectHandle txStream, unsigned int bufferSize, UINT16 segmentSize, UINT16 blockSize) + { + tx_stream = txStream; + tx_segment_size = segmentSize; + tx_stream_buffer_max = NormGetStreamBufferSegmentCount(bufferSize, segmentSize, blockSize); + tx_stream_buffer_max -= blockSize; // a little safety margin (perhaps not necessary) + tx_stream_buffer_count = 0; + tx_stream_bytes_remain = 0; + tx_watermark_pending = false; + } + + + bool Listen(NormInstanceHandle instance, UINT16 serverPort, const char* groupAddr); + NormSocket* Accept(NormNodeHandle client, NormInstanceHandle instance = NORM_INSTANCE_INVALID); + bool Connect(NormInstanceHandle instance, const char* serverAddr, UINT16 serverPort, const char* groupAddr, NormNodeId clientId); + + + // Write to tx stream (with flow control) + unsigned int Write(const char* buffer, unsigned int numBytes); + void Flush(bool eom = false, NormFlushMode flushMode = NORM_FLUSH_ACTIVE); + // Read from rx_stream + bool Read(char* buffer, unsigned int& numBytes); + + // "graceful" shutdown (stream is flushed and stream end, etc) + void Shutdown(); + + // hard, immediate closure + void Close(); + + void GetSocketEvent(const NormEvent& event, NormSocketEvent& socketEvent); + + typedef enum State + { + CLOSED, + LISTENING, + CONNECTING, + ACCEPTING, + CONNECTED, + CLOSING + } State; + + bool AddAckingNode(NormNodeId nodeId) + { + if (NormAddAckingNode(norm_session, nodeId)) + { + client_count++; + return true; + } + else + { + return false; + } + } + void RemoveAckingNode(NormNodeId nodeId) + {NormRemoveAckingNode(norm_session, nodeId);} + + + private: + State socket_state; + NormSessionHandle norm_session; + NormSessionHandle mcast_session; // equals norm_session for a multicast server + NormSocket* server_socket; // only applies to server-side sockets + unsigned int client_count; // only applies to mcast server sockets + NormNodeId client_id; // only applies to mcast client socket + NormNodeHandle remote_node; // + // Send stream and associated flow control state variables + NormObjectHandle tx_stream; + bool tx_ready; + UINT16 tx_segment_size; + unsigned int tx_stream_buffer_max; + unsigned int tx_stream_buffer_count; + unsigned int tx_stream_bytes_remain; + bool tx_watermark_pending; + // Receive stream state + NormObjectHandle rx_stream; + +}; // end class NormSocket + + +NormSocket::NormSocket(NormSessionHandle normSession) + : socket_state(CLOSED), norm_session(normSession), + mcast_session(NORM_SESSION_INVALID), server_socket(NULL), + client_count(0), client_id(NORM_NODE_NONE), remote_node(NORM_NODE_INVALID), + tx_stream(NORM_OBJECT_INVALID), tx_ready(false), tx_segment_size(0), + tx_stream_buffer_max(0), tx_stream_buffer_count(0), + tx_stream_bytes_remain(0), tx_watermark_pending(false), + rx_stream(NORM_OBJECT_INVALID) +{ + // For now we use the NormSession "user data" option to associate + // the session with a "socket". In the future we may add a + // dedicated NormSetSocket(NormSessionHandle session, NormSocketHandle normSocket) API + // to keep the "user data" feature available for other purposes + if (NORM_SESSION_INVALID != normSession) // this should always be true + NormSetUserData(normSession, this); +} + + +bool NormSocket::Listen(NormInstanceHandle instance, UINT16 serverPort, const char* groupAddr) +{ + if (CLOSED != socket_state) + { + fprintf(stderr, "NormSocket::Listen() error: socket already open?!\n"); + return false; + } + + if (NULL != groupAddr) + { + // TBD - validate that "groupAddr" is indeed a multicast address + norm_session = NormCreateSession(instance, groupAddr, serverPort, NORM_NODE_ANY); + NormSetTxPort(norm_session, serverPort); // can't do this and receive unicast feedback + mcast_session = norm_session; + } + else + { + // For unicast , the "server" has a NormNodeId of '1' and the "clients" are '2' + // to obviate need for explicit id management and will allow NAT to work, etc + norm_session = NormCreateSession(instance, "127.0.0.1", serverPort, 1); + } + if (NORM_SESSION_INVALID == norm_session) + { + fprintf(stderr, "NormSocket::Listen() error: NormCreateSession() failure\n"); + return false; + } + NormSetUserData(norm_session, this); + // Note the port reuse here lets us manage our "client" rx-only unicast connections the + // way we need, but does allow a second multicast server to be started on this group which leads + // to undefined behavior. TBD - see if we can prevent via binding wizardry + // (How is it done for TCP servers? - probably because the accept() call is in the network stack + // instead of user-space) Perhaps we could have a semaphore lock to block a second "server" + NormSetRxPortReuse(norm_session, true); + + // use default sync policy so a "serversocket" doesn't NACK the senders it detects + // NORM_SYNC_STREAM tries to get everything the sender has cached/buffered + //NormSetDefaultSyncPolicy(norm_session, NORM_SYNC_STREAM); + //NormSetDefaultSyncPolicy(norm_session, NORM_SYNC_ALL); + + if (NULL == groupAddr) + { + // Unicast server + // Note we use a small buffer size here since a "listening" socket isn't + // going to be receiving data (TBD - implement a mechanism to handoff remote + // sender (i.e. "client") from parent + if (!NormStartReceiver(norm_session, 2048)) + { + fprintf(stderr, "NormSocket::Listen() error: NormStartReceiver() failure (perhaps port already in use)\n"); + NormDestroySession(norm_session); + norm_session = NORM_SESSION_INVALID; + } + } + else + { + //NormSetMulticastInterface(norm_session, "lo0"); + NormSetMulticastLoopback(norm_session, true); // for testing + if (!NormStartReceiver(norm_session, 2048)) + { + fprintf(stderr, "NormSocket::Listen() error: NormStartReceiver() failure (perhaps port already in use)\n"); + NormDestroySession(norm_session); + norm_session = NORM_SESSION_INVALID; + } + // TBD - We _could_ go ahead and call NormStartSender(), but for now we'll wait until we hear the application + // makes at least one NormAccept() call ... + } + server_socket = this; + socket_state = LISTENING; + return true; +} // end NormSocket::Listen() + +NormSocket* NormSocket::Accept(NormNodeHandle client, NormInstanceHandle instance) +{ + if (!IsServerSocket()) return NULL; + char clientAddr[64]; + clientAddr[63] = '\0'; + char addr[16]; // big enough for IPv6 + unsigned int addrLen = 16; + UINT16 clientPort; + NormNodeGetAddress(client, addr, &addrLen, &clientPort); + int addrFamily; + UINT8 version; + if (4 == addrLen) + { + addrFamily = AF_INET; + version = 4; + } + else + { + addrFamily = AF_INET6; + version = 6; + } + inet_ntop(addrFamily, addr, clientAddr, 63); + + UINT16 serverPort = NormGetRxPort(norm_session); + if (NORM_INSTANCE_INVALID == instance) + instance = NormGetInstance(norm_session); + + NormSessionHandle clientSession = NormCreateSession(instance, clientAddr, serverPort, 1); + + NormSetTxPort(clientSession, serverPort, false); + + // This next API call will cause NORM to tightly bind the remote client src addr/port to + // our server port so the "clientSession" captures the client packets instead of the "server" session + + // Any new packets will come to our new connected clientSession instead + // However, note that even though we've "connected" this sender, + // there is a chance that additional packets in the "serverSession" + // rx socket buffer may look like a new sender if deleted now, so + // we wait for NORM_REMOTE_SENDER_INACTIVE to delete + + // NORM_SYNC_STREAM tries to get everything the sender has cached/buffered + //NormSetDefaultSyncPolicy(norm_session, NORM_SYNC_STREAM); + NormSetDefaultSyncPolicy(norm_session, NORM_SYNC_ALL); + + NormSetRxPortReuse(clientSession, true, 0, clientAddr, clientPort); // "connects" to remote client addr/port + NormSetDefaultUnicastNack(clientSession, true); + + NormStartReceiver(clientSession, 2*1024*1024); + + NormSocket* clientSocket = new NormSocket(clientSession); + clientSocket->server_socket = this; // this is a server-side socket + clientSocket->remote_node = client; + NormNodeSetUserData(client, clientSocket); + + NormNodeId clientId = NormNodeGetId(client); + + if (IsUnicastSocket()) + { + // The clientSession is bi-directional so we need to NormStartSender(), etc + NormAddAckingNode(clientSession, 2); //clientId); + NormSetFlowControl(clientSession, 0); // disable timer-based flow control since we do explicit, ACK-based flow control + NormStartSender(clientSession, NormGetRandomSessionId(), 2*1024*1024, 1400, 16, 4); + } + else // if IsMulticastSocket() + { + // TBD - should we make sure this not a NormNodeId we already have? + // TBD - should we wait to add the client as acking node until CONNECT + // (probably for heavyweight; for lightweight we know the client + // has already started his multicast receiver) + AddAckingNode(clientId); // TBD - check result + NormNodeHandle node = NormGetAckingNodeHandle(mcast_session, clientId); + NormNodeSetUserData(node, clientSocket); // a way to track mcast client sockets + clientSocket->mcast_session = mcast_session; + clientSocket->client_id = client_id; + if (LISTENING == socket_state) + { + NormSetFlowControl(norm_session, 0); // disable timer-based flow control since we do explicit, ACK-based flow control + NormStartSender(norm_session, NormGetRandomSessionId(), 2*1024*1024, 1400, 16, 4); + socket_state = CONNECTED; + } + /* The code below would be invoked for "heavyweight" mcast client admission + (for the moment we go with a "lightweight" model - this might be invokable upon + as an optional behavior later) + + // Here, we start the clientSession (w/ a minimal buffer size) and create a temporary sender + // stream that is immediately flushed/closed to inform the "client" that his connection + // has been accepted. The sender function is terminated upon client acknowledgement + NormAddAckingNode(clientSession, clientId); + NormSetFlowControl(clientSession, 0); // disable timer-based flow control since we do explicit, ACK-based flow control + NormStartSender(clientSession, NormGetRandomSessionId(), 1024, 512, 1, 0); + NormObjectHandle tempStream = NormStreamOpen(clientSession, 1024); + NormStreamClose(tempStream, true); // Note our "trick" here to do a graceful close, _then_ watermark to get ack + NormSetWatermark(clientSession, tempStream, true); // future NORM API will add "bool watermark" option to graceful close + */ + } + clientSocket->socket_state = ACCEPTING; // will transision to CONNECTED when client is detected on new clientSession + return clientSocket; +} // end NormSocket::Accept() + +// TBD - provide options for binding to a specific local address, interface, etc +bool NormSocket::Connect(NormInstanceHandle instance, const char* serverAddr, UINT16 serverPort, const char* groupAddr, NormNodeId clientId) +{ + // For unicast connections, the "client" manages a single NormSession for send and receive + // (For multicast connections, there are two sessions: The same unicast session that will + // be set to txOnly upon CONNECT and a NormSession for multicast reception) + norm_session = NormCreateSession(instance, "127.0.0.1", 0, clientId); // TBD - use "clientId" here for mcast sockets? + if (NORM_SESSION_INVALID == norm_session) + { + fprintf(stderr, "NormSocket::Connect() error: NormCreateSession() failure\n"); + return false; + } + // NORM_SYNC_STREAM tries to get everything the sender has cached/buffered + //NormSetDefaultSyncPolicy(norm_session, NORM_SYNC_STREAM); + NormSetDefaultSyncPolicy(norm_session, NORM_SYNC_ALL); + + NormSetUserData(norm_session, this); + NormSetRxPortReuse(norm_session, true, NULL, serverAddr, serverPort); + // TBD - for a multicast connection, the unicast receiver could be started with minimal buffer + // (not that it matters since the buffers aren't activated until a sender starts sending _data_) + if (!NormStartReceiver(norm_session, 2*1024*1024)) // to get ephemeral port assigned + { + fprintf(stderr, "NormSocket::Connect() error: unicast NormStartReceiver() failure\n"); + return false; + } + NormChangeDestination(norm_session, serverAddr, serverPort, false); // "connect" our NORM tx_socket (so we can get ICMP) + NormSessionId sessionId = NormGetRandomSessionId(); + NormAddAckingNode(norm_session, 1); // servers always have NormNodeId '1' + NormSetFlowControl(norm_session, 0); // since we do explicit, ACK-based flow control + if (!NormStartSender(norm_session, sessionId, 2*1024*1024, 1400, 16, 4)) + { + fprintf(stderr, "NormSocket::Connect() error: NormStartSender() failure\n"); + return false; + } + + if (NULL != groupAddr) + { + // Create the "mcast_session" for multicast reception + mcast_session = NormCreateSession(instance, groupAddr, serverPort, clientId); + //NormSetTxPort(mcast_session, serverPort); // TBD - not sure this is a good idea if multiple clients on a machine? + NormSetUserData(mcast_session, this); + // NORM_SYNC_STREAM tries to get everything the sender has cached/buffered + //NormSetDefaultSyncPolicy(mcast_session, NORM_SYNC_STREAM); + NormSetDefaultSyncPolicy(mcast_session, NORM_SYNC_ALL); + + NormSetDefaultUnicastNack(mcast_session, true); // we could optionally allow multicast NACKing, too + NormSetMulticastLoopback(norm_session, true); // for testing + client_id = clientId; + // TBD - make this SSM??? ... this would allow for multiple servers using the same groupAddr/port + NormSetRxPortReuse(mcast_session, true, groupAddr); // Should we upgrade rx port reuse and 'connect' to server tx port upon CONNECT? + // For a "lightweight" client->server connection establishment, we go ahead and + // stop our unicast receiver and start multicast receiver, assuming the server + // will admit us into the group. + // (TBD - provide a "heavier weight" connection acceptance confirmation/denial signal from server + // via unicast from server -> client here (i.e. keep the unicast receiver open) + if (!NormStartReceiver(mcast_session, 2*1024*1024)) // to get ephemeral port assigned + { + fprintf(stderr, "NormSocket::Connect() error: multicast NormStartReceiver() failure\n"); + return false; + } + } + else + { + // Set timeout for connect attempt (for "heavyweight" mcast connect, this would also be done) + NormSetUserTimer(norm_session, NORM_DEFAULT_CONNECT_TIMEOUT); + } + server_socket = NULL; // this is a client-side socket + + socket_state = CONNECTING; + + return true; +} // end NormSocket::Connect() + + +unsigned int NormSocket::Write(const char* buffer, unsigned int numBytes) +{ + // TBD - make sure the socket is CONNECTED first + if (IsMulticastClient() && IsServerSide()) + { + // This is multicast server rxonly client socket, so we redirect + // the write() to the associated txonly multicast socket + return server_socket->Write(buffer, numBytes); + } + // TBD - if tx_stream not yet open, open it!!! + if (NORM_OBJECT_INVALID == tx_stream) + { + tx_stream = NormStreamOpen(norm_session, 2*1024*1024); + InitTxStream(tx_stream, 2*1024*1024, 1400, 16); + } + + // This method uses NormStreamWrite(), but limits writes by explicit ACK-based flow control status + if (tx_stream_buffer_count < tx_stream_buffer_max) + { + // 1) How many buffer bytes are available? + unsigned int bytesAvailable = tx_segment_size * (tx_stream_buffer_max - tx_stream_buffer_count); + bytesAvailable -= tx_stream_bytes_remain; // unflushed segment portiomn + if (numBytes <= bytesAvailable) + { + unsigned int totalBytes = numBytes + tx_stream_bytes_remain; + unsigned int numSegments = totalBytes / tx_segment_size; + tx_stream_bytes_remain = totalBytes % tx_segment_size; + tx_stream_buffer_count += numSegments; + } + else + { + numBytes = bytesAvailable; + tx_stream_buffer_count = tx_stream_buffer_max; + } + // 2) Write to the stream + unsigned int bytesWritten = NormStreamWrite(tx_stream, buffer, numBytes); + //assert(bytesWritten == numBytes); // this could happen if timer-based flow control is left enabled + // 3) Check if we need to issue a watermark ACK request? + if (!tx_watermark_pending && (tx_stream_buffer_count >= (tx_stream_buffer_max / 2))) + { + //fprintf(stderr, "tx_engine_t::WriteToNormStream() initiating watermark ACK request (buffer count:%lu max:%lu usage:%u)...\n", + // tx_stream_buffer_count, tx_stream_buffer_max, NormStreamGetBufferUsage(tx_stream)); + NormSetWatermark(norm_session, tx_stream); + tx_watermark_pending = true; + } + return bytesWritten; + } + else + { + return 0; + } +} // end NormSocket::Write() + +void NormSocket::Flush(bool eom, NormFlushMode flushMode) +{ + // TBD - make sure the socket is CONNECTED first + if (IsMulticastClient() && IsServerSide()) + { + // This is multicast server rxOnly client socket, so we redirect + // the flush() to the associated txonly multicast socket + return server_socket->Flush(eom, flushMode); + } + + // NormStreamFlush always will transmit pending runt segments, if applicable + // (thus we need to manage our buffer counting accordingly if pending bytes remain) + if (tx_watermark_pending) + { + NormStreamFlush(tx_stream, eom, flushMode); + } + else if (NORM_FLUSH_ACTIVE == flushMode) + { + // we flush passive, because watermark forces active ack request + NormStreamFlush(tx_stream, eom, NORM_FLUSH_PASSIVE); + NormSetWatermark(norm_session, tx_stream, true); + } + else + { + NormStreamFlush(tx_stream, eom, flushMode); + } + + if (0 != tx_stream_bytes_remain) + { + // The flush forces the runt segment out, so we increment our buffer usage count + tx_stream_buffer_count++; + tx_stream_bytes_remain = 0; + if (!tx_watermark_pending && (tx_stream_buffer_count >= (tx_stream_buffer_max >> 1))) + { + //fprintf(stderr, "tx_engine_t::stream_flush() initiating watermark ACK request (buffer count:%lu max:%lu usage:%u)...\n", + // tx_stream_buffer_count, tx_stream_buffer_max); + NormSetWatermark(norm_session, tx_stream, true); + tx_watermark_pending = true; + } + } + } // end NormSocket::Flush() + + bool NormSocket::Read(char* buffer, unsigned int& numBytes) + { + // TBD - make sure rx_stream is valid! + // TBD - make sure this is not a tx only client socket ... + return NormStreamRead(rx_stream, buffer, &numBytes); + } // end NormSocket::Read() + + void NormSocket::Shutdown() + { + if ((NORM_OBJECT_INVALID == tx_stream) || + (IsServerSide() && IsMulticastClient())) + { + Close(); // close immediately since this socket doesn't control a tx_stream + } + else + { + // It controls a tx_stream, so shutdown the tx_stream gracefully + NormStreamClose(tx_stream, true); // Note our "trick" here to do a graceful close, _then_ watermark to get ack + NormSetWatermark(norm_session, tx_stream, true); // future NORM API will add "bool watermark" option to graceful close + socket_state = CLOSING; + } + } // end NormSocket::Shutdown() + + void NormSocket::Close() + { + if (IsMulticastSocket()) + { + if (IsServerSide()) + { + if (IsServerSocket()) + { + // IsMulticastSocket() guarantees the mcast_session is valid + // Dissociate remaining clients from this session and set their + // timer so that NORM_SOCKET_CLOSED events are dispatched for them + NormNodeId nodeId = NORM_NODE_NONE; + while (NormGetNextAckingNode(mcast_session, &nodeId)) + { + NormNodeHandle node = NormGetAckingNodeHandle(mcast_session, nodeId); + assert(NORM_NODE_INVALID != node); + NormSocket* clientSocket = (NormSocket*)NormNodeGetUserData(node); + NormSetUserTimer(clientSocket->norm_session, 0.0); + } + // for mcast server mcast_session == norm_session so it's destroyed below + } + else + { + // "IsServerSide()" guarantees the "server_socket" is non-NULL + // server-side multicast client socket closing, so we + // need to remove this "client" NormNodeId from the mcast + // session's acking node list + server_socket->RemoveAckingNode(client_id); + } + } + else // client-side multicast socket, so we need to destroy mcast_session, too + { + NormDestroySession(mcast_session); + } + mcast_session = NORM_SESSION_INVALID; + } + if (NORM_SESSION_INVALID != norm_session) + { + NormDestroySession(norm_session); + norm_session = NORM_SESSION_INVALID; + } + server_socket = NULL; + tx_stream = NORM_OBJECT_INVALID; + tx_segment_size = 0; + tx_stream_buffer_max = tx_stream_buffer_count = tx_stream_bytes_remain = 0; + tx_watermark_pending = false; + rx_stream = NORM_OBJECT_INVALID; + socket_state = CLOSED; + } // end NormSocket::Close() + + +void NormSocket::GetSocketEvent(const NormEvent& event, NormSocketEvent& socketEvent) +{ + socketEvent.socket = (NormSocketHandle)this; + socketEvent.type = NORM_SOCKET_NONE; // default socket event type if no socket-specific state change occurs + socketEvent.event = event; + switch (event.type) + { + case NORM_TX_QUEUE_EMPTY: + case NORM_TX_QUEUE_VACANCY: + { + // The socket may be tx ready, so issue a NORM_SOCKET_WRITE event + if (CONNECTED == socket_state) + { + if (!tx_ready) + { + tx_ready = true; + socketEvent.type = NORM_SOCKET_WRITE; + } + } + break; + } + case NORM_TX_WATERMARK_COMPLETED: + { + switch (socket_state) + { + case ACCEPTING: + { + // This only comes into play for the "confirmed connection" + // model for multicast sockets (not yet implemented) + assert(0); + assert(IsServerSide() && IsMulticastClient()); + if (NORM_ACK_SUCCESS == NormGetAckingStatus(norm_session)) + { + // Client has acknowledged our acceptance + socketEvent.type = NORM_SOCKET_CONNECT; + NormStopSender(norm_session); // the mcast_session is our tx channel + break; + } + else + { + // Client didn't acknowledge, so we cull him from our server + Close(); + socketEvent.type = NORM_SOCKET_CLOSED; + } + break; + } + case CLOSING: + { + // Socket that was shutdown has either been acknowledged or timed out + // TBD - should we issue a different event if ACK_FAILURE??? + Close(); + socketEvent.type = NORM_SOCKET_CLOSED; + break; + } + default: + { + // TBD - implement option for more persistence + bool success = false; + if (NORM_ACK_SUCCESS == NormGetAckingStatus(norm_session)) + { + success = true; + } + else + { + // At least one receiver didn't acknowledge + if (IsUnicastSocket() || IsMulticastClient()) + { + // We could be infinitely persistent w/ NormResetWatermark() + //NormResetWatermark(event.session); + // For now, we'll just declare the connection broken/closed + Close(); + socketEvent.type = NORM_SOCKET_CLOSED; + } + else + { + // Multicast server, so determine who failed to acknowledge + // and cull them from our acking node list ... and shutdown + // their associated unicast sockets ... ugh!!! + NormNodeId nodeId = NORM_NODE_NONE; + NormAckingStatus ackingStatus; + while (NormGetNextAckingNode(mcast_session, &nodeId, &ackingStatus)) + { + if (NORM_ACK_SUCCESS == ackingStatus) + { + success = true; // there was at least one success + } + else + { + NormNodeHandle node = NormGetAckingNodeHandle(mcast_session, nodeId); + assert(NORM_NODE_INVALID != node); + NormSocket* clientSocket = (NormSocket*)NormNodeGetUserData(node); + assert(NULL != clientSocket); + // We use the session timer to dispatch a NORM_SOCKET_CLOSED per failed client + // (This will also remove the client from this server's acking list) + NormSetUserTimer(clientSocket->norm_session, 0.0); + clientSocket->socket_state = CLOSING; + } + } + // TBD - what do we if all clients failed ... issue a NORM_SOCKET_DISCONNECT event, + // probably stop sending data and resume when a new client appears ??? + } + } + if (tx_watermark_pending && success) + { + // flow control acknowledgement + tx_watermark_pending = false; + tx_stream_buffer_count -= (tx_stream_buffer_max >> 1); + if (!tx_ready) + { + tx_ready = true; + socketEvent.type = NORM_SOCKET_WRITE; + } + } + break; + } + } + break; + } + case NORM_REMOTE_SENDER_RESET: + case NORM_REMOTE_SENDER_NEW: + { + switch (socket_state) + { + case LISTENING: + socketEvent.type = NORM_SOCKET_ACCEPT; + break; + case ACCEPTING: + if (IsServerSide() && IsClientSocket() && (NORM_NODE_INVALID != remote_node)) + NormNodeDelete(remote_node); + case CONNECTING: + // TBD - We should validate that it's the right remote sender + // (i.e., by source address and/or nodeId) + NormCancelUserTimer(norm_session); + socketEvent.type = NORM_SOCKET_CONNECT; + socket_state = CONNECTED; + remote_node = event.sender; + break; + case CONNECTED: + if (IsMulticastSocket()) + { + if (IsServerSocket()) + { + // New client showing up at our multicast party + socketEvent.type = NORM_SOCKET_ACCEPT; + } + else + { + // Different sender showing up in multicast group!? + fprintf(stderr, "NormSocket warning: multicast sender %s reset?!\n", NormNodeGetAddressString(event.sender)); + // TBD - should Close() the socket and issue a NORM_SOCKET_CLOSED event + // and leave it up to the application to reconnect? Or should we + // provides some sort of NORM_SOCKET_DISCONNECT event + socketEvent.type = NORM_SOCKET_CLOSED; + Close(); + } + } + else // unicast + { + // Eemote sender reset? How do we tell? + fprintf(stderr, "NormSocket warning: unicast sender %s reset?!\n", NormNodeGetAddressString(event.sender)); + socketEvent.type = NORM_SOCKET_CLOSED; + Close(); + } + break; + + default: // CLOSING, CLOSED + // shouldn't happen + break; + } + break; + } + case NORM_SEND_ERROR: + { + switch (socket_state) + { + case CONNECTING: + case ACCEPTING: + case CONNECTED: + case CLOSING: + if (IsMulticastServer()) + fprintf(stderr, "SEND_ERROR on a multicast server socket?!\n"); + socketEvent.event.sender = remote_node; + socketEvent.type = NORM_SOCKET_CLOSED; + Close(); + break; + default: + // shouldn't happen + break; + } + break; + } + + case NORM_USER_TIMEOUT: + { + switch (socket_state) + { + case CONNECTING: // client connection attempt timed out + case ACCEPTING: // accepted client didn't follow through + case CONNECTED: // multicast client ack failure + case CLOSING: + socketEvent.event.sender = remote_node; + socketEvent.type = NORM_SOCKET_CLOSED; + Close(); + break; + default: + // shouldn't happen + assert(0); + break; + } + break; + } + case NORM_REMOTE_SENDER_INACTIVE: + { + switch (socket_state) + { + case LISTENING: + { + // delete state for remote sender that has been accepted (or not) + // TBD - do something a little more tidy here + NormSocket* clientSocket = (NormSocket*)NormNodeGetUserData(event.sender); + if ((NULL != clientSocket) && (clientSocket->remote_node == event.sender)) + clientSocket->remote_node = NORM_NODE_INVALID; + NormNodeDelete(event.sender); + break; + } + case CONNECTED: + { + if (IsServerSocket()) + { + NormSocket* clientSocket = (NormSocket*)NormNodeGetUserData(event.sender); + if ((NULL != clientSocket) && (clientSocket->remote_node == event.sender)) + clientSocket->remote_node = NORM_NODE_INVALID; + NormNodeDelete(event.sender); + } + // TBD - should we do something here (perhaps issue a NORM_SOCKET_IDLE event or something + // that could be used as a clue that our "connection" may have broken or timed out??? + // (Meanwhile, applications will have to figure that our for themselves) + break; + } + default: // CONNECTING, ACCEPTING, CLOSING, CLOSED + { + // shouldn't happen + break; + } + } + break; + } + case NORM_RX_OBJECT_NEW: + { + switch (socket_state) + { + case LISTENING: + // TBD - shouldn't happen, delete sender right away? + break; + case CONNECTED: + // TBD - make sure the sender is who we expect it to be??? + if (IsServerSocket()) break; + if (NORM_OBJECT_INVALID == rx_stream) + { + // We're expecting this, new stream ready for reading ... + InitRxStream(event.object); + socketEvent.type = NORM_SOCKET_READ; + } + else + { + // Stream reset + fprintf(stderr, "NormSocket::GetSocketEvent(): client stream reset?!\n"); + } + break; + default: // CONNECTING, ACCEPTING, CLOSING, CLOSED + // shouldn't happen + break; + } + break; + } + case NORM_RX_OBJECT_UPDATED: + { + switch (socket_state) + { + case CONNECTED: + case CLOSING: // we allow reading during graceful closure + // TBD - use an rx_ready indication to filter this event a little more + if (IsServerSocket()) break; // we don't receive data on server socket + assert(event.object == rx_stream); + socketEvent.type = NORM_SOCKET_READ; + break; + default: + // shouldn't happen + break; + } + break; + } + case NORM_RX_OBJECT_COMPLETED: + { + rx_stream = NORM_OBJECT_INVALID; + switch (socket_state) + { + case CONNECTED: + // Initiate graceful closure of our tx_stream to allow at least some time to + // acknowledge the remote before closing everything down + NormStreamClose(tx_stream, true); // Note our "trick" here to do a graceful close, _then_ watermark to get ack + NormSetWatermark(norm_session, tx_stream, true); // future NORM API will add "bool watermark" option to graceful close + socket_state = CLOSING; + socketEvent.type = NORM_SOCKET_CLOSING; + break; + + case CLOSING: + // We're already closing, so just let that complete. This helps make sure we allow + // at least some time to acknowledge the remote before closing everything down + break; + default: + // shouldn't happen + break; + } + } + default: + break; + } +} // end NormSocket::GetSocketEvent() + + + + /////////////////////////////////////////////////////////////////////////////////// + // NormSocket API implementation + +// TBD - provide options for binding to a specific local address, interface, etc +NormSocketHandle NormListen(NormInstanceHandle instance, UINT16 serverPort, const char* groupAddr) +{ + // TBD - check results + NormSocket* normSocket = new NormSocket(); + normSocket->Listen(instance, serverPort, groupAddr); + return (NormSocketHandle)normSocket; +} // end NormListen() + + +NormSocketHandle NormAccept(NormSocketHandle serverSocket, NormNodeHandle client) +{ + // TBD - VALIDATE PARAMETERS AND ERROR CHECK ALL THE API CALLS MADE HERE !!!!! + NormSocket* s = (NormSocket*)serverSocket; + return (NormSocketHandle)(s->Accept(client)); +} // end NormAccept() + + +// TBD - provide options for binding to a specific local address, interface, etc +NormSocketHandle NormConnect(NormInstanceHandle instance, const char* serverAddr, UINT16 serverPort, const char* groupAddr, NormNodeId clientId) +{ + NormSocket* normSocket = new NormSocket(); + if (NULL == normSocket) + { + perror("NormConnect() new NormSocket() error"); + return NULL; + } + if (normSocket->Connect(instance, serverAddr, serverPort, groupAddr, clientId)) + { + return normSocket; + } + else + { + delete normSocket; + return NULL; + } +} // end NormConnect() + + +ssize_t NormWrite(NormSocketHandle normSocket, const void *buf, size_t nbyte) +{ + // TBD - we could make write() and read() optionally blocking or non-blocking + // by using GetSocketEvent() as appropriate (incl. returning error conditions, etc) + NormSocket* s = (NormSocket*)normSocket; + return (ssize_t)s->Write((const char*)buf, nbyte); +} // end NormWrite() + +int NormFlush(NormSocketHandle normSocket) +{ + NormSocket* s = (NormSocket*)normSocket; + s->Flush(); + return 0; +} // end NormFlush() + +ssize_t NormRead(NormSocketHandle normSocket, void *buf, size_t nbyte) +{ + // TBD - we could make write() and read() optionally blocking or non-blocking + // by using GetSocketEvent() as appropriate (incl. returning error conditions, etc) + NormSocket* s = (NormSocket*)normSocket; + // TBD - make sure s->rx_stream is valid + unsigned int numBytes = nbyte; + if (s->Read((char*)buf, numBytes)) + return numBytes; + else + return -1; // broken stream error (TBD - enumerate socket error values) +} // end NormWrite() + + +void NormShutdown(NormSocketHandle normSocket) +{ + NormSocket* s = (NormSocket*)normSocket; + s->Shutdown(); +} // end NormShutdown() + +void NormClose(NormSocketHandle normSocket) +{ + NormSocket* s = (NormSocket*)normSocket; + s->Close(); +} // end NormClose() + +// This gets and translates low level NORM API events to NormSocket events +// given the "normSocket" state +bool NormGetSocketEvent(NormInstanceHandle instance, NormSocketEvent* socketEvent, bool waitForEvent) +{ + if (NULL == socketEvent) return false; + NormEvent event; + if (NormGetNextEvent(instance, &event, waitForEvent)) + { + NormSocket* normSocket = NULL; + if (NORM_SESSION_INVALID != event.session) + normSocket = (NormSocket*)NormGetUserData(event.session); + if (NULL == normSocket) + { + socketEvent->type = NORM_SOCKET_NONE; + socketEvent->socket = NORM_SOCKET_INVALID; + socketEvent->event = event; + } + else + { + normSocket->GetSocketEvent(event, *socketEvent); + } + return true; + } + else + { + return false; + } +} // end NormGetSocketEvent() + +// Other helper functions + +NormSessionHandle NormGetSession(NormSocketHandle normSocket) +{ + NormSocket* s = (NormSocket*)normSocket; + return s->GetSession(); +} // end NormGetSession() + +NormSessionHandle NormGetMulticastSession(NormSocketHandle normSocket) +{ + NormSocket* s = (NormSocket*)normSocket; + return s->GetMulticastSession(); +} // end NormGetSession() diff --git a/examples/normSocket.h b/examples/normSocket.h new file mode 100644 index 0000000..a4e3ebb --- /dev/null +++ b/examples/normSocket.h @@ -0,0 +1,120 @@ + +#ifndef _NORM_SOCKET +#define _NORM_SOCKET + +// IMPORTANT NOTE: THIS IS A WORK IN PROGRESS. This code, if/when fully developed, will be +// "promoted" from the 'examples' directory to a standard part of the NORM +// library if appropriate. + +// This provides a higher level API that facilitates a socket-like programming interface +// to use NORM for a specific usage pattern. The usage pattern uses NORM_OBJECT_STREAM +// (as a byte-stream initially with eventual support for NORM's message-stream capability, too) +// where "clients" explicitly connect to a "server" and bi-directional stream communication is +// established. This enables ACK-based flow control to/from the server and client(s). This +// is supported for NORM unicast and also (as this is completed) an asymmetric model where the +// server can multicast to the clients while the clients unicast back to the server. + + +// TODO: +// +// 0) Make "NormInstanceHandle" optional for Listen/Connect/Accept +// (for eventual blocking usage, it wouldn't be needed) +// 1) Support asymmetric server->multicast, client->unicast model +// 2) Provide non-blocking option for read/write calls +// 3) leverage ICMP (e.g., port unreachable) feedback to detect connect() failure (DONE) +// 4) provide means for connect() to time out??? (DONE) +// 5) Separate socket open (i.e. session creation) from connect/accept to allow +// opportunity for application to set NORM parameters prior to sender/receiver start +// 6) Extend to include message stream, and data/file object sockets +// 7) Option to associate NORM_INFO w/ stream (or objects eventually) + + +// Here is a list of NORM parameters that need to be set _before_ sender or receiver +// startup. These will need to be "NormSocket" parameters that can be set after +// NormOpen() but before NormListen(), NormAccept(), or NormConnect(): +// +// a) SSM source address (perhaps incorporate into NormListen() and NormConnect()?) +// b) TTL (could be set _after_ connect/accept, but may be something convenient to preset? +// c) TOS (same as for TTL) +// d) Fragmentation (not one to worry much about initially?) +// e) FEC parameters (block size, parity count, segment size, "auto" parity) +// f) Buffer size (sender, stream, receiver) +// g) cache bounds / limits + +#include "normApi.h" + +typedef const void* NormSocketHandle; + +extern const NormSocketHandle NORM_SOCKET_INVALID; + +extern const double NORM_DEFAULT_CONNECT_TIMEOUT; + +#ifndef NULL +#define NULL 0 +#endif // !NULL + +// Main NormSocket API Functions + +NormSocketHandle NormOpen(NormInstanceHandle instance = NORM_INSTANCE_INVALID); + +NormSocketHandle NormListen(NormInstanceHandle instance, UINT16 serverPort, const char* groupAddr = NULL); + +NormSocketHandle NormConnect(NormInstanceHandle instance, + const char* serverAddr, + UINT16 serverPort, + const char* groupAddr = NULL, + NormNodeId clientId = NORM_NODE_NONE); + +NormSocketHandle NormAccept(NormSocketHandle serverSocket, NormNodeHandle clientNode, NormInstanceHandle instance = NORM_INSTANCE_INVALID); + +void NormShutdown(NormSocketHandle normSocket); + +void NormClose(NormSocketHandle normSocket); + +ssize_t NormRead(NormSocketHandle normSocket, void *buf, size_t nbyte); + +ssize_t NormWrite(NormSocketHandle normSocket, const void *buf, size_t nbyte); + +int NormFlush(NormSocketHandle normSocket); + +// Helper API functions + +NormSessionHandle NormGetSession(NormSocketHandle normSocket); +NormSessionHandle NormGetMulticastSession(NormSocketHandle normSocket); + +typedef enum NormSocketEventType +{ + NORM_SOCKET_NONE = 0, + NORM_SOCKET_ACCEPT, // only issued for listening server sockets + NORM_SOCKET_CONNECT, // notification confirming connection to server + NORM_SOCKET_READ, // edge-triggered notification that socket is ready for reading + NORM_SOCKET_WRITE, // edge-triggered notification that socket is ready for writing + NORM_SOCKET_CLOSING, // indicates remote endpoint is closing socket (only read data at this point) + NORM_SOCKET_CLOSED // indicates socket is now closed (invalid for further operations) +} NormSocketEventType; + +typedef struct +{ + NormSocketEventType type; + NormSocketHandle socket; + // The underlying NormEvent is embedded. The union + // here lets us access the NormEvent fields directly. + // (E.g., *.sender, *.object, etc. as needed) + union + { + NormEvent event; // underlying NormEvent that evoked this socketEvent + struct + { + NormEventType etype; // underlying NormEventType + NormSessionHandle session; // NormEvent session + NormNodeHandle sender; // NormEvent sender + NormObjectHandle object; // NormEvent object + }; + }; +} NormSocketEvent; + +bool NormGetSocketEvent(NormInstanceHandle normInstance, NormSocketEvent* event, bool waitForEvent = true); + + + +#endif // !_NORM_SOCKET diff --git a/include/normApi.h b/include/normApi.h index 7708f66..6e8b702 100644 --- a/include/normApi.h +++ b/include/normApi.h @@ -173,6 +173,8 @@ typedef enum NormEventType NORM_TX_RATE_CHANGED, NORM_LOCAL_SENDER_CLOSED, NORM_REMOTE_SENDER_NEW, + NORM_REMOTE_SENDER_RESET, // remote sender instanceId or FEC params changed + NORM_REMOTE_SENDER_ADDRESS, // remote sender src addr and/or port changed NORM_REMOTE_SENDER_ACTIVE, NORM_REMOTE_SENDER_INACTIVE, NORM_REMOTE_SENDER_PURGED, // not yet implemented @@ -184,7 +186,10 @@ typedef enum NormEventType NORM_RX_OBJECT_ABORTED, NORM_GRTT_UPDATED, NORM_CC_ACTIVE, - NORM_CC_INACTIVE + NORM_CC_INACTIVE, + NORM_ACKING_NODE_NEW, // whe NormSetAutoAcking xxx + NORM_SEND_ERROR, // ICMP error (e.g. destination unreachable) + NORM_USER_TIMEOUT // issues when timeout set by NormSetUserTimer() expires } NormEventType; typedef struct @@ -222,7 +227,6 @@ NORM_API_LINKAGE void NormResumeInstance(NormInstanceHandle instanceHandle); - // This MUST be set to enable NORM_OBJECT_FILE reception! // (otherwise received files are ignored) NORM_API_LINKAGE @@ -263,6 +267,9 @@ NormSessionHandle NormCreateSession(NormInstanceHandle instanceHandle, NORM_API_LINKAGE void NormDestroySession(NormSessionHandle sessionHandle); +NORM_API_LINKAGE +NormInstanceHandle NormGetInstance(NormSessionHandle sessionHandle); + NORM_API_LINKAGE bool NormIsUnicastAddress(const char* address); @@ -272,10 +279,19 @@ void NormSetUserData(NormSessionHandle sessionHandle, const void* userData); NORM_API_LINKAGE const void* NormGetUserData(NormSessionHandle sessionHandle); +NORM_API_LINKAGE +void NormSetUserTimer(NormSessionHandle sessionHandle, double seconds); + +NORM_API_LINKAGE +void NormCancelUserTimer(NormSessionHandle sessionHandle); + NORM_API_LINKAGE NormNodeId NormGetLocalNodeId(NormSessionHandle sessionHandle); +NORM_API_LINKAGE +UINT16 NormGetRxPort(NormSessionHandle sessionHandle); + NORM_API_LINKAGE bool NormSetTxPort(NormSessionHandle sessionHandle, UINT16 txPortNumber, @@ -291,12 +307,13 @@ void NormSetTxOnly(NormSessionHandle sessionHandle, bool connectToSessionAddress DEFAULT(false)); -// This does not affect the rx_socket binding if already bound +// This does not affect the rx_socket binding if already bound (sender or receiver already started) // (i.e., just affects where NORM packets are sent) NORM_API_LINKAGE bool NormChangeDestination(NormSessionHandle sessionHandle, const char* sessionAddress, - UINT16 sessionPort); + UINT16 sessionPort, + bool connectToSessionAddress DEFAULT(false)); NORM_API_LINKAGE void NormSetRxPortReuse(NormSessionHandle sessionHandle, @@ -319,6 +336,10 @@ NORM_API_LINKAGE bool NormSetMulticastInterface(NormSessionHandle sessionHandle, const char* interfaceName); +NORM_API_LINKAGE +bool NormSetSSM(NormSessionHandle sessionHandle, + const char* sourceAddress); + NORM_API_LINKAGE bool NormSetTTL(NormSessionHandle sessionHandle, unsigned char ttl); @@ -331,6 +352,10 @@ NORM_API_LINKAGE bool NormSetLoopback(NormSessionHandle sessionHandle, bool loopback); +NORM_API_LINKAGE +bool NormSetMulticastLoopback(NormSessionHandle sessionHandle, + bool loopback); + NORM_API_LINKAGE bool NormSetFragmentation(NormSessionHandle sessionHandle, @@ -375,13 +400,17 @@ double NormGetReportInterval(NormSessionHandle sessionHandle); NORM_API_LINKAGE NormSessionId NormGetRandomSessionId(); + +// This function has been updated so that 16-bit Reed-Solomon +// codecs can be accessed. This may cause an issue for linking +// to older versions of the NORM library NORM_API_LINKAGE bool NormStartSender(NormSessionHandle sessionHandle, NormSessionId instanceId, UINT32 bufferSpace, UINT16 segmentSize, - unsigned char numData, - unsigned char numParity); + UINT16 numData, + UINT16 numParity); NORM_API_LINKAGE void NormStopSender(NormSessionHandle sessionHandle); @@ -529,6 +558,10 @@ NORM_API_LINKAGE void NormRemoveAckingNode(NormSessionHandle sessionHandle, NormNodeId nodeId); +NORM_API_LINKAGE +NormNodeHandle NormGetAckingNodeHandle(NormSessionHandle sessionHandle, + NormNodeId nodeId); + NORM_API_LINKAGE void NormSetAutoAckingNodes(NormSessionHandle sessionHandle, NormTrackingStatus trackingStatus); @@ -540,7 +573,7 @@ NormAckingStatus NormGetAckingStatus(NormSessionHandle sessionHandle, NORM_API_LINKAGE bool NormGetNextAckingNode(NormSessionHandle sessionHandle, NormNodeId* nodeId, - NormAckingStatus* ackingStatus); + NormAckingStatus* ackingStatus DEFAULT(0)); NORM_API_LINKAGE bool NormSendCommand(NormSessionHandle sessionHandle, @@ -687,6 +720,12 @@ bool NormNodeGetAddress(NormNodeHandle nodeHandle, unsigned int* bufferLen, UINT16* port DEFAULT((UINT16*)0)); +NORM_API_LINKAGE +void NormNodeSetUserData(NormNodeHandle nodeHandle, const void* userData); + +NORM_API_LINKAGE +const void* NormNodeGetUserData(NormNodeHandle nodeHandle); + NORM_API_LINKAGE double NormNodeGetGrtt(NormNodeHandle remoteSender); @@ -702,7 +741,22 @@ void NormNodeFreeBuffers(NormNodeHandle remoteSender); NORM_API_LINKAGE void NormNodeDelete(NormNodeHandle remoteSender); -// The next 4 functions have not yet been implemented +NORM_API_LINKAGE +void NormNodeRetain(NormNodeHandle nodeHandle); + +NORM_API_LINKAGE +void NormNodeRelease(NormNodeHandle nodeHandle); + +/** Some experimental functions */ + +NORM_API_LINKAGE +void NormReleasePreviousEvent(NormInstanceHandle instanceHandle); + +NORM_API_LINKAGE +UINT32 NormCountCompletedObjects(NormSessionHandle sessionHandle); + + +// The next functions have _not_ yet been implemented // (work in progress) NORM_API_LINKAGE void NormNodeSetAutoDelete(NormNodeHandle remoteSender, @@ -712,19 +766,7 @@ NORM_API_LINKAGE bool NormNodeAllowSender(NormNodeId senderId); NORM_API_LINKAGE -bool NormNodeDenySender(NormNodeId senderId); - - -NORM_API_LINKAGE -void NormNodeRetain(NormNodeHandle nodeHandle); - -NORM_API_LINKAGE -void NormNodeRelease(NormNodeHandle nodeHandle); - -/** Some experimental functions */ - -NORM_API_LINKAGE -UINT32 NormCountCompletedObjects(NormSessionHandle sessionHandle); +bool NormNodeDenySender(NormNodeId senderId); #ifdef __cplusplus } // end extern "C" diff --git a/include/normMessage.h b/include/normMessage.h index 26bcf5d..057df7b 100644 --- a/include/normMessage.h +++ b/include/normMessage.h @@ -120,12 +120,12 @@ class NormObjectSize NormObjectSize(UINT16 msb, UINT32 lsb) { size = (Offset)lsb; -#if _FILE_OFFSET_BITS > 32 +#if (_FILE_OFFSET_BITS > 32) && !defined(ANDROID) size |= ((Offset)msb) << 32; #endif } Offset GetOffset() const {return size;} -#if _FILE_OFFSET_BITS > 32 +#if (_FILE_OFFSET_BITS > 32) && !defined(ANDROID) UINT16 MSB() const {return ((UINT16)((size >> 32) & 0x0000ffff));} #else UINT16 MSB() const {return 0;} diff --git a/include/normNode.h b/include/normNode.h index 511d2f2..22876a4 100644 --- a/include/normNode.h +++ b/include/normNode.h @@ -14,13 +14,28 @@ class NormNode friend class NormNodeListIterator; public: - NormNode(class NormSession& theSession, NormNodeId nodeId); + enum Type + { + ACKER, + SENDER, + CC_NODE + }; + + NormNode(Type theType, class NormSession& theSession, NormNodeId nodeId); virtual ~NormNode(); + Type GetType() const + {return node_type;} + NormSession& GetSession() const {return session;} void Retain(); void Release(); + void SetUserData(const void* userData) + {user_data = userData;} + const void* GetUserData() const + {return user_data;} + const ProtoAddress& GetAddress() const {return addr;} void SetAddress(const ProtoAddress& address) {addr = address;} const NormNodeId& GetId() const {return id;} @@ -52,9 +67,11 @@ class NormNode class NormSession& session; private: + Type node_type; NormNodeId id; ProtoAddress addr; unsigned int reference_count; + const void* user_data; // We keep NormNodes in a binary tree (TBD) make this a ProtoTree NormNode* parent; NormNode* right; @@ -544,6 +561,7 @@ class NormSenderNode : public NormNode // Watermark acknowledgement ProtoTimer ack_timer; + bool ack_pending; NormObjectId watermark_object_id; NormBlockId watermark_block_id; NormSegmentId watermark_segment_id; diff --git a/include/normSession.h b/include/normSession.h index d031e5e..7bea248 100644 --- a/include/normSession.h +++ b/include/normSession.h @@ -40,6 +40,8 @@ class NormController TX_RATE_CHANGED, LOCAL_SENDER_CLOSED, REMOTE_SENDER_NEW, + REMOTE_SENDER_RESET, + REMOTE_SENDER_ADDRESS, REMOTE_SENDER_ACTIVE, REMOTE_SENDER_INACTIVE, REMOTE_SENDER_PURGED, @@ -51,13 +53,16 @@ class NormController RX_OBJECT_ABORTED, GRTT_UPDATED, CC_ACTIVE, // posted when cc feedback is detected - CC_INACTIVE // posted when no cc feedback and min rate reached + CC_INACTIVE, // posted when no cc feedback and min rate reached + ACKING_NODE_NEW, + SEND_ERROR, + USER_TIMEOUT }; virtual void Notify(NormController::Event event, class NormSessionMgr* sessionMgr, class NormSession* session, - class NormSenderNode* sender, + class NormNode* node, class NormObject* object) = 0; }; // end class NormController @@ -81,11 +86,11 @@ class NormSessionMgr void Notify(NormController::Event event, class NormSession* session, - class NormSenderNode* sender, + class NormNode* node, class NormObject* object) { if (controller) - controller->Notify(event, this, session, sender, object); + controller->Notify(event, this, session, node, object); } void ActivateTimer(ProtoTimer& timer) {timer_mgr.ActivateTimer(timer);} @@ -163,6 +168,7 @@ class NormSession const ProtoAddress& Address() {return address;} void SetAddress(const ProtoAddress& addr) {address = addr;} bool SetMulticastInterface(const char* interfaceName); + bool SetSSM(const char* sourceAddress); bool SetTTL(UINT8 theTTL) { bool result = tx_socket->IsOpen() ? tx_socket->SetTTL(theTTL) : true; @@ -179,11 +185,18 @@ class NormSession } bool SetLoopback(bool state) { - bool result = tx_socket->IsOpen() ? tx_socket->SetLoopback(state) : true; + bool result = state ? SetMulticastLoopback(true) : true; loopback = result ? state : loopback; return result; } + bool SetMulticastLoopback(bool state) + { + bool result = tx_socket->IsOpen() ? tx_socket->SetLoopback(state) : true; + mcast_loopback = result ? state : mcast_loopback; + return result; + } + bool SetFragmentation(bool state) { bool result = tx_socket->IsOpen() ? tx_socket->SetFragmentation(state) : true; @@ -289,11 +302,11 @@ class NormSession unsigned long countMin, unsigned long countMax); void Notify(NormController::Event event, - class NormSenderNode* sender, + class NormNode* node, class NormObject* object) { notify_pending = true; - session_mgr.Notify(event, this, sender, object); + session_mgr.Notify(event, this, node, object); notify_pending = false; } @@ -308,6 +321,8 @@ class NormSession const void* GetUserData() const {return user_data;} + void SetUserTimer(double seconds); // set to value less than zero to cancel + // Sender methods void SenderSetBaseObjectId(NormObjectId baseId) { @@ -322,6 +337,8 @@ class NormSession UINT16 numParity); void StopSender(); void SetTxOnly(bool txOnly, bool connectToSessionAddress = false); + bool GetTxOnly() const + {return tx_only;} NormStreamObject* QueueTxStream(UINT32 bufferSize, bool doubleBuffer = false, @@ -353,11 +370,16 @@ class NormSession void SenderSetAutoAckingNodes(TrackingStatus trackingStatus) {acking_auto_populate = trackingStatus;} - bool SenderAddAckingNode(NormNodeId nodeId); + NormAckingNode* SenderAddAckingNode(NormNodeId nodeId, const ProtoAddress* srcAddr = NULL); void SenderRemoveAckingNode(NormNodeId nodeId); AckingStatus SenderGetAckingStatus(NormNodeId nodeId); // Set "prevNodeId = NORM_NODE_NONE" to init this iteration (returns "false" when done) bool SenderGetNextAckingNode(NormNodeId& prevNodeId, AckingStatus* ackingStatus = NULL); + + NormAckingNode* SenderFindAckingNode(NormNodeId nodeId) const + { + return static_cast(acking_node_tree.FindNodeById(nodeId)); + } // App-defined command support methods bool SenderSendCmd(const char* cmdBuffer, unsigned int cmdLength, bool robust); @@ -557,6 +579,7 @@ class NormSession bool OnReportTimeout(ProtoTimer& theTimer); bool OnCmdTimeout(ProtoTimer& theTimer); bool OnFlowControlTimeout(ProtoTimer& theTimer); + bool OnUserTimeout(ProtoTimer& theTimer); void TxSocketRecvHandler(ProtoSocket& theSocket, ProtoSocket::Event theEvent); void RxSocketRecvHandler(ProtoSocket& theSocket, ProtoSocket::Event theEvent); @@ -624,12 +647,14 @@ class NormSession // General session parameters NormNodeId local_node_id; - ProtoAddress address; // session destination address/port - UINT8 ttl; // session multicast ttl - UINT8 tos; // session IPv4 TOS (or IPv6 traffic class - TBD) - bool loopback; // receive own traffic it true - bool fragmentation; // enable UDP/IP fragmentation (i.e. clear DF bit) if true - bool ecn_enabled; // set true to get raw packets and check for ECN status + ProtoAddress address; // session destination address/port + ProtoAddress ssm_source_addr; // optional SSM source address + UINT8 ttl; // session multicast ttl + UINT8 tos; // session IPv4 TOS (or IPv6 traffic class - TBD) + bool loopback; // receive own traffic it true + bool mcast_loopback; // enable socket multicast loopback if true + bool fragmentation; // enable UDP/IP fragmentation (i.e. clear DF bit) if true + bool ecn_enabled; // set true to get raw packets and check for ECN status char interface_name[IFACE_NAME_MAX+1]; double tx_rate; // bytes per second @@ -763,6 +788,7 @@ class NormSession double rx_loss_rate; // for uncorrelated loss double report_timer_interval; + ProtoTimer user_timer; const void* user_data; // Linkers @@ -774,6 +800,7 @@ void NormTrace(const struct timeval& currentTime, NormNodeId localId, const NormMsg& msg, bool sent, - UINT8 fecM); + UINT8 fecM, + UINT16 instId = 0); // this might not always be available to caller #endif // _NORM_SESSION diff --git a/include/normVersion.h b/include/normVersion.h index fe83e11..685004b 100644 --- a/include/normVersion.h +++ b/include/normVersion.h @@ -36,6 +36,6 @@ #ifndef _NORM_VERSION #define _NORM_VERSION -#define VERSION "1.5b4" +#define VERSION "1.5r5" #endif // _NORM_VERSION diff --git a/makefiles/Makefile.common b/makefiles/Makefile.common index a53bffd..782f17b 100644 --- a/makefiles/Makefile.common +++ b/makefiles/Makefile.common @@ -15,6 +15,7 @@ NS = ../src/sim/ns INCLUDES = $(SYSTEM_INCLUDES) -I$(UNIX) -I../include -I$(PROTOLIB)/include CFLAGS = -g -DPROTO_DEBUG -DUNIX -D_FILE_OFFSET_BITS=64 -O $(SYSTEM_CFLAGS) $(SYSTEM_HAVES) $(INCLUDES) +#CFLAGS = -g -DPROTO_DEBUG -DUNIX -D_FILE_OFFSET_BITS=64 $(SYSTEM_CFLAGS) $(SYSTEM_HAVES) $(INCLUDES) LDFLAGS = $(SYSTEM_LDFLAGS) @@ -239,7 +240,7 @@ gtf: $(GTF_OBJ) cp $@ ../bin/$@ clean: - rm -f $(COMMON)/*.o $(UNIX)/*.o $(NS)/*.o \ + rm -f $(COMMON)/*.o $(UNIX)/*.o $(NS)/*.o $(EXAMPLE)/*.o \ libnorm.a libnorm.$(SYSTEM_SOEXT) ../lib/libnorm.a ../lib/libnorm.$(SYSTEM_SOEXT) \ norm raft normTest normTest2 normThreadTest normThreadTest2 ../bin/*; $(MAKE) -C $(PROTOLIB)/makefiles -f Makefile.$(SYSTEM) clean diff --git a/makefiles/Makefile.freebsd b/makefiles/Makefile.freebsd index 3b3f68e..612c234 100644 --- a/makefiles/Makefile.freebsd +++ b/makefiles/Makefile.freebsd @@ -40,9 +40,10 @@ SYSTEM_HAVES = -DHAVE_IPV6 -DHAVE_ASSERT -DHAVE_GETLOGIN -DHAVE_FLOCK -DHAVE_DI SYSTEM_SRC = SYSTEM = freebsd -CC = g++ +CC = c++ SYSTEM_CFLAGS = -fPIC -Wall -pedantic -Wcast-align -SYSTEM_SOFLAGS = -shared +SYSTEM_SOFLAGS = -shared +SYSTEM_SOEXT = so RANLIB = ranlib AR = ar diff --git a/makefiles/Makefile.macosx b/makefiles/Makefile.macosx index 1ed670b..f8c802e 100644 --- a/makefiles/Makefile.macosx +++ b/makefiles/Makefile.macosx @@ -37,7 +37,7 @@ SYSTEM_LIBS = -lresolv -lpcap # SYSTEM_HAVES = -DMACOSX -DECN_SUPPORT -DHAVE_IPV6 -DHAVE_ASSERT -DHAVE_GETLOGIN -DHAVE_FLOCK \ --D_FILE_OFFSET_BITS=64 -DHAVE_DIRFD +-D_FILE_OFFSET_BITS=64 -DHAVE_DIRFD -DUSE_SELECT SYSTEM_SRC = ../protolib/src/unix/bpfCap.cpp diff --git a/makefiles/win32/Norm-2008.sln b/makefiles/win32/Norm-2008.sln new file mode 100644 index 0000000..026f01d --- /dev/null +++ b/makefiles/win32/Norm-2008.sln @@ -0,0 +1,63 @@ +Microsoft Visual Studio Solution File, Format Version 10.00 +# Visual Studio 2008 +Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "NormLib", "NormLib.vcproj", "{D7B0023C-8798-4918-8DA0-05C9054D70B9}" + ProjectSection(ProjectDependencies) = postProject + {DE94F096-A09B-44B6-8EFE-C7BF1F65C4C9} = {DE94F096-A09B-44B6-8EFE-C7BF1F65C4C9} + EndProjectSection +EndProject +Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "norm", "norm\norm.vcproj", "{6E1308A6-D40F-489E-A4F1-40D859380D64}" + ProjectSection(ProjectDependencies) = postProject + {D7B0023C-8798-4918-8DA0-05C9054D70B9} = {D7B0023C-8798-4918-8DA0-05C9054D70B9} + EndProjectSection +EndProject +Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "normTest", "normTest.vcproj", "{32CF83E0-D2E0-4E43-8F7B-72BD0AB64647}" + ProjectSection(ProjectDependencies) = postProject + {DE94F096-A09B-44B6-8EFE-C7BF1F65C4C9} = {DE94F096-A09B-44B6-8EFE-C7BF1F65C4C9} + {182006F3-188F-466E-89FE-8421C0478691} = {182006F3-188F-466E-89FE-8421C0478691} + EndProjectSection +EndProject +Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "NormDll", "NormDll.vcproj", "{182006F3-188F-466E-89FE-8421C0478691}" + ProjectSection(ProjectDependencies) = postProject + {DE94F096-A09B-44B6-8EFE-C7BF1F65C4C9} = {DE94F096-A09B-44B6-8EFE-C7BF1F65C4C9} + EndProjectSection +EndProject +Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "npc", "npc.vcproj", "{7BF4525B-9185-4296-A2BF-FFE77BB66EAF}" + ProjectSection(ProjectDependencies) = postProject + {D7B0023C-8798-4918-8DA0-05C9054D70B9} = {D7B0023C-8798-4918-8DA0-05C9054D70B9} + EndProjectSection +EndProject +Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Protokit", "..\..\protolib\makefiles\win32\Protokit.vcproj", "{DE94F096-A09B-44B6-8EFE-C7BF1F65C4C9}" +EndProject +Global + GlobalSection(SolutionConfigurationPlatforms) = preSolution + Debug|Win32 = Debug|Win32 + Release|Win32 = Release|Win32 + EndGlobalSection + GlobalSection(ProjectConfigurationPlatforms) = postSolution + {D7B0023C-8798-4918-8DA0-05C9054D70B9}.Debug|Win32.ActiveCfg = Debug|Win32 + {D7B0023C-8798-4918-8DA0-05C9054D70B9}.Debug|Win32.Build.0 = Debug|Win32 + {D7B0023C-8798-4918-8DA0-05C9054D70B9}.Release|Win32.ActiveCfg = Release|Win32 + {D7B0023C-8798-4918-8DA0-05C9054D70B9}.Release|Win32.Build.0 = Release|Win32 + {6E1308A6-D40F-489E-A4F1-40D859380D64}.Debug|Win32.ActiveCfg = Debug|Win32 + {6E1308A6-D40F-489E-A4F1-40D859380D64}.Debug|Win32.Build.0 = Debug|Win32 + {6E1308A6-D40F-489E-A4F1-40D859380D64}.Release|Win32.ActiveCfg = Release|Win32 + {6E1308A6-D40F-489E-A4F1-40D859380D64}.Release|Win32.Build.0 = Release|Win32 + {32CF83E0-D2E0-4E43-8F7B-72BD0AB64647}.Debug|Win32.ActiveCfg = Debug|Win32 + {32CF83E0-D2E0-4E43-8F7B-72BD0AB64647}.Debug|Win32.Build.0 = Debug|Win32 + {32CF83E0-D2E0-4E43-8F7B-72BD0AB64647}.Release|Win32.ActiveCfg = Release|Win32 + {32CF83E0-D2E0-4E43-8F7B-72BD0AB64647}.Release|Win32.Build.0 = Release|Win32 + {182006F3-188F-466E-89FE-8421C0478691}.Debug|Win32.ActiveCfg = Debug|Win32 + {182006F3-188F-466E-89FE-8421C0478691}.Debug|Win32.Build.0 = Debug|Win32 + {182006F3-188F-466E-89FE-8421C0478691}.Release|Win32.ActiveCfg = Release|Win32 + {182006F3-188F-466E-89FE-8421C0478691}.Release|Win32.Build.0 = Release|Win32 + {7BF4525B-9185-4296-A2BF-FFE77BB66EAF}.Debug|Win32.ActiveCfg = Debug|Win32 + {7BF4525B-9185-4296-A2BF-FFE77BB66EAF}.Release|Win32.ActiveCfg = Release|Win32 + {DE94F096-A09B-44B6-8EFE-C7BF1F65C4C9}.Debug|Win32.ActiveCfg = Debug|Win32 + {DE94F096-A09B-44B6-8EFE-C7BF1F65C4C9}.Debug|Win32.Build.0 = Debug|Win32 + {DE94F096-A09B-44B6-8EFE-C7BF1F65C4C9}.Release|Win32.ActiveCfg = Release|Win32 + {DE94F096-A09B-44B6-8EFE-C7BF1F65C4C9}.Release|Win32.Build.0 = Release|Win32 + EndGlobalSection + GlobalSection(SolutionProperties) = preSolution + HideSolutionNode = FALSE + EndGlobalSection +EndGlobal diff --git a/makefiles/win32/Norm.sln b/makefiles/win32/Norm.sln index 026f01d..4fb993f 100644 --- a/makefiles/win32/Norm.sln +++ b/makefiles/win32/Norm.sln @@ -1,32 +1,18 @@ -Microsoft Visual Studio Solution File, Format Version 10.00 -# Visual Studio 2008 -Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "NormLib", "NormLib.vcproj", "{D7B0023C-8798-4918-8DA0-05C9054D70B9}" - ProjectSection(ProjectDependencies) = postProject - {DE94F096-A09B-44B6-8EFE-C7BF1F65C4C9} = {DE94F096-A09B-44B6-8EFE-C7BF1F65C4C9} - EndProjectSection +Microsoft Visual Studio Solution File, Format Version 12.00 +# Visual Studio Express 2013 for Windows Desktop +VisualStudioVersion = 12.0.30723.0 +MinimumVisualStudioVersion = 10.0.40219.1 +Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "NormLib", "NormLib.vcxproj", "{D7B0023C-8798-4918-8DA0-05C9054D70B9}" EndProject -Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "norm", "norm\norm.vcproj", "{6E1308A6-D40F-489E-A4F1-40D859380D64}" - ProjectSection(ProjectDependencies) = postProject - {D7B0023C-8798-4918-8DA0-05C9054D70B9} = {D7B0023C-8798-4918-8DA0-05C9054D70B9} - EndProjectSection +Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "norm", "norm\norm.vcxproj", "{6E1308A6-D40F-489E-A4F1-40D859380D64}" EndProject -Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "normTest", "normTest.vcproj", "{32CF83E0-D2E0-4E43-8F7B-72BD0AB64647}" - ProjectSection(ProjectDependencies) = postProject - {DE94F096-A09B-44B6-8EFE-C7BF1F65C4C9} = {DE94F096-A09B-44B6-8EFE-C7BF1F65C4C9} - {182006F3-188F-466E-89FE-8421C0478691} = {182006F3-188F-466E-89FE-8421C0478691} - EndProjectSection +Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "normTest", "normTest.vcxproj", "{32CF83E0-D2E0-4E43-8F7B-72BD0AB64647}" EndProject -Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "NormDll", "NormDll.vcproj", "{182006F3-188F-466E-89FE-8421C0478691}" - ProjectSection(ProjectDependencies) = postProject - {DE94F096-A09B-44B6-8EFE-C7BF1F65C4C9} = {DE94F096-A09B-44B6-8EFE-C7BF1F65C4C9} - EndProjectSection +Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "NormDll", "NormDll.vcxproj", "{182006F3-188F-466E-89FE-8421C0478691}" EndProject -Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "npc", "npc.vcproj", "{7BF4525B-9185-4296-A2BF-FFE77BB66EAF}" - ProjectSection(ProjectDependencies) = postProject - {D7B0023C-8798-4918-8DA0-05C9054D70B9} = {D7B0023C-8798-4918-8DA0-05C9054D70B9} - EndProjectSection +Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "npc", "npc.vcxproj", "{7BF4525B-9185-4296-A2BF-FFE77BB66EAF}" EndProject -Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Protokit", "..\..\protolib\makefiles\win32\Protokit.vcproj", "{DE94F096-A09B-44B6-8EFE-C7BF1F65C4C9}" +Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Protokit", "..\..\protolib\makefiles\win32\Protokit.vcxproj", "{DE94F096-A09B-44B6-8EFE-C7BF1F65C4C9}" EndProject Global GlobalSection(SolutionConfigurationPlatforms) = preSolution diff --git a/makefiles/win32/Norm.suo b/makefiles/win32/Norm.suo index 2d18e97..e5c1144 100644 Binary files a/makefiles/win32/Norm.suo and b/makefiles/win32/Norm.suo differ diff --git a/makefiles/win32/NormDll.vcxproj b/makefiles/win32/NormDll.vcxproj new file mode 100755 index 0000000..fa07e73 --- /dev/null +++ b/makefiles/win32/NormDll.vcxproj @@ -0,0 +1,125 @@ + + + + + Debug + Win32 + + + Release + Win32 + + + + {182006F3-188F-466E-89FE-8421C0478691} + Win32Proj + + + + DynamicLibrary + v120 + MultiByte + + + DynamicLibrary + v120 + MultiByte + + + + + + + + + + + + + + + <_ProjectFileVersion>11.0.50727.1 + + + Debug\ + Debug\ + true + + + Release\ + Release\ + false + + + + Disabled + ..\..\include;..\..\protolib\include;%(AdditionalIncludeDirectories) + NORM_USE_DLL;PROTO_DEBUG;HAVE_IPV6;HAVE_ASSERT;WIN32;_LIB;_CRT_SECURE_NO_WARNINGS;%(PreprocessorDefinitions) + true + EnableFastChecks + MultiThreadedDebugDLL + + Level3 + EditAndContinue + + + ws2_32.lib;iphlpapi.lib;%(AdditionalDependencies) + $(OutDir)Norm.dll + true + $(OutDir)NormDll.pdb + Windows + false + + $(OutDir)Norm.lib + MachineX86 + + + + + ..\..\include;..\..\protolib\include;%(AdditionalIncludeDirectories) + NORM_USE_DLL;NDEBUG;PROTO_DEBUG;HAVE_IPV6;HAVE_ASSERT;WIN32;_LIB;_CRT_SECURE_NO_WARNINGS;%(PreprocessorDefinitions) + MultiThreadedDLL + + Level3 + ProgramDatabase + + + ws2_32.lib;iphlpapi.lib;%(AdditionalDependencies) + $(OutDir)Norm.dll + true + Windows + true + true + false + + $(OutDir)Norm.lib + MachineX86 + + + + + + + + + + + + + + + + + + + + + + {de94f096-a09b-44b6-8efe-c7bf1f65c4c9} + false + + + + + + \ No newline at end of file diff --git a/makefiles/win32/NormLib.vcxproj b/makefiles/win32/NormLib.vcxproj new file mode 100755 index 0000000..432612f --- /dev/null +++ b/makefiles/win32/NormLib.vcxproj @@ -0,0 +1,121 @@ + + + + + Debug + Win32 + + + Release + Win32 + + + + {D7B0023C-8798-4918-8DA0-05C9054D70B9} + + + + StaticLibrary + v120_xp + false + MultiByte + + + StaticLibrary + v120_xp + false + MultiByte + + + + + + + + + + + + + + + <_ProjectFileVersion>11.0.50727.1 + + + .\Debug\ + .\Debug\ + + + .\Release\ + .\Release\ + + + + Disabled + ..\..\include;..\..\protolib\include;%(AdditionalIncludeDirectories) + PROTO_DEBUG;HAVE_IPV6;HAVE_ASSERT;WIN32;_LIB;_CRT_SECURE_NO_WARNINGS;%(PreprocessorDefinitions) + EnableFastChecks + MultiThreadedDebugDLL + + .\Debug/NormLib.pch + .\Debug/ + .\Debug/ + .\Debug/ + Level3 + true + Default + + + _DEBUG;%(PreprocessorDefinitions) + 0x0409 + + + .\Debug\NormLib.lib + true + + + + + MaxSpeed + OnlyExplicitInline + ..\..\include;..\..\protolib\include;%(AdditionalIncludeDirectories) + NDEBUG;PROTO_DEBUG;HAVE_IPV6;HAVE_ASSERT;WIN32;_LIB;_CRT_SECURE_NO_WARNINGS;%(PreprocessorDefinitions) + true + MultiThreadedDLL + true + + .\Release/NormLib.pch + .\Release/ + .\Release/ + .\Release/ + Level3 + true + Default + + + NDEBUG;%(PreprocessorDefinitions) + 0x0409 + + + .\Release\NormLib.lib + true + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/makefiles/win32/README.TXT b/makefiles/win32/README.TXT new file mode 100755 index 0000000..5efe011 --- /dev/null +++ b/makefiles/win32/README.TXT @@ -0,0 +1,15 @@ +Visual Studio 2012 and 2013 require different versions of the Platform Toolset: + +Visual Studio 2012 v110 (or v110_xp for applications that need to run +under Windows XP) + +Visual Studio 2013 v120 (or v120_xp for applications that need to run +under Windows XP) + +For each project included by the solution file modify the Platform +Toolset under project Configuration Properties, General as appropriate +for your Visual Studio version. + +A Visual Studio solutions file and associated .vcproj files are +included as a convenience for those using earlier versions of visual +studio (2008 and 2010): Norm-2008.sln diff --git a/makefiles/win32/norm/norm.vcxproj b/makefiles/win32/norm/norm.vcxproj new file mode 100755 index 0000000..a4772f4 --- /dev/null +++ b/makefiles/win32/norm/norm.vcxproj @@ -0,0 +1,155 @@ + + + + + Debug + Win32 + + + Release + Win32 + + + + {6E1308A6-D40F-489E-A4F1-40D859380D64} + + + + Application + v120 + false + MultiByte + + + Application + v120 + false + MultiByte + + + + + + + + + + + + + + + <_ProjectFileVersion>11.0.61030.0 + + + .\Debug\ + .\Debug\ + false + + + .\Release\ + .\Release\ + false + + + + _DEBUG;%(PreprocessorDefinitions) + true + true + Win32 + .\Debug/norm.tlb + + + + /vmg %(AdditionalOptions) + Disabled + ..\..\..\include;..\..\..\protolib\include;%(AdditionalIncludeDirectories) + _DEBUG;PROTO_DEBUG;HAVE_IPV6;HAVE_ASSERT;WIN32;_CRT_SECURE_NO_WARNINGS;_WINDOWS;%(PreprocessorDefinitions) + EnableFastChecks + MultiThreadedDebugDLL + + .\Debug/norm.pch + .\Debug/ + .\Debug/ + .\Debug/ + Level3 + true + EditAndContinue + Default + + + _DEBUG;%(PreprocessorDefinitions) + 0x0409 + + + iphlpapi.lib;ws2_32.lib;odbc32.lib;odbccp32.lib;%(AdditionalDependencies) + .\Debug/norm.exe + true + true + .\Debug/norm.pdb + Windows + false + + MachineX86 + + + + + NDEBUG;%(PreprocessorDefinitions) + true + true + Win32 + .\Release/norm.tlb + + + + /vmg %(AdditionalOptions) + MaxSpeed + OnlyExplicitInline + ..\..\..\include;..\..\..\protolib\include;%(AdditionalIncludeDirectories) + NDEBUG;PROTO_DEBUG;HAVE_IPV6;HAVE_ASSERT;WIN32;_WINDOWS;_CRT_SECURE_NO_WARNINGS;%(PreprocessorDefinitions) + true + MultiThreadedDLL + true + + .\Release/norm.pch + .\Release/ + .\Release/ + .\Release/ + true + Level3 + true + Default + + + NDEBUG;%(PreprocessorDefinitions) + 0x0409 + + + iphlpapi.lib;ws2_32.lib;odbc32.lib;odbccp32.lib;%(AdditionalDependencies) + .\Release/norm.exe + true + .\Release/norm.pdb + Windows + false + + MachineX86 + + + + + + + + + + {de94f096-a09b-44b6-8efe-c7bf1f65c4c9} + + + {d7b0023c-8798-4918-8da0-05c9054d70b9} + + + + + + \ No newline at end of file diff --git a/makefiles/win32/normTest.vcxproj b/makefiles/win32/normTest.vcxproj new file mode 100755 index 0000000..873b847 --- /dev/null +++ b/makefiles/win32/normTest.vcxproj @@ -0,0 +1,149 @@ + + + + + Debug + Win32 + + + Release + Win32 + + + + {32CF83E0-D2E0-4E43-8F7B-72BD0AB64647} + normTest + + + + Application + v120 + false + MultiByte + + + Application + v120 + false + MultiByte + + + + + + + + + + + + + + + <_ProjectFileVersion>11.0.50727.1 + + + .\Debug\ + .\Debug\ + + + + .\Release\ + .\Release\ + false + false + + + + .\Debug/normTest.tlb + + + + Disabled + ..\..\include;..\..\protolib\include;%(AdditionalIncludeDirectories) + NORM_USE_DLL;PROTO_DEBUG;HAVE_ASSERT;WIN32;_CRT_SECURE_NO_WARNINGS;%(PreprocessorDefinitions) + EnableFastChecks + MultiThreadedDebugDLL + true + + .\Debug/normTest.pch + .\Debug/ + .\Debug/ + .\Debug/ + Level3 + true + EditAndContinue + Default + + + _DEBUG;%(PreprocessorDefinitions) + 0x0409 + + + iphlpapi.lib;ws2_32.lib;odbc32.lib;odbccp32.lib;%(AdditionalDependencies) + .\Debug/normTest.exe + true + ./;%(AdditionalLibraryDirectories) + true + .\Debug/normTest.pdb + Console + false + + MachineX86 + + + + + .\Release/normTest.tlb + + + + MaxSpeed + OnlyExplicitInline + ..\..\include;..\..\protolib\include;%(AdditionalIncludeDirectories) + NORM_USE_DLL;PROTO_DEBUG;WIN32;HAVE_ASSERT;_CRT_SECURE_NO_WARNINGS;%(PreprocessorDefinitions) + true + MultiThreadedDLL + true + + .\Release/normTest.pch + .\Release/ + .\Release/ + .\Release/ + Level3 + true + ProgramDatabase + Default + + + NDEBUG;%(PreprocessorDefinitions) + 0x0409 + + + iphlpapi.lib;ws2_32.lib;odbc32.lib;odbccp32.lib;%(AdditionalDependencies) + .\Release/normTest.exe + true + .\Release/normTest.pdb + Console + false + + MachineX86 + + + + + + + + {de94f096-a09b-44b6-8efe-c7bf1f65c4c9} + false + + + {182006f3-188f-466e-89fe-8421c0478691} + false + + + + + + \ No newline at end of file diff --git a/makefiles/win32/npc.vcxproj b/makefiles/win32/npc.vcxproj new file mode 100755 index 0000000..8198a7d --- /dev/null +++ b/makefiles/win32/npc.vcxproj @@ -0,0 +1,141 @@ + + + + + Debug + Win32 + + + Release + Win32 + + + + {7BF4525B-9185-4296-A2BF-FFE77BB66EAF} + normTest + + + + Application + v120 + false + MultiByte + + + Application + v120 + false + MultiByte + + + + + + + + + + + + + + + <_ProjectFileVersion>11.0.50727.1 + + + .\Debug\ + .\Debug\ + + + + .\Release\ + .\Release\ + false + false + + + + .\Debug/normTest.tlb + + + + Disabled + ..\..\include;..\..\protolib\include;%(AdditionalIncludeDirectories) + PROTO_DEBUG;HAVE_IPV6;HAVE_ASSERT;WIN32;_CRT_SECURE_NO_WARNINGS;%(PreprocessorDefinitions) + EnableFastChecks + MultiThreadedDebugDLL + true + + .\Debug/normTest.pch + .\Debug/ + .\Debug/ + .\Debug/ + Level3 + true + EditAndContinue + Default + + + _DEBUG;%(PreprocessorDefinitions) + 0x0409 + + + iphlpapi.lib;ws2_32.lib;odbc32.lib;odbccp32.lib;%(AdditionalDependencies) + true + ./;%(AdditionalLibraryDirectories) + true + Windows + false + + MachineX86 + + + + + .\Release/normTest.tlb + + + + MaxSpeed + OnlyExplicitInline + ..\..\include;..\..\protolib\include;%(AdditionalIncludeDirectories) + NDEBUG;PROTO_DEBUG;HAVE_IPV6;HAVE_ASSERT;WIN32;_CRT_SECURE_NO_WARNINGS;%(PreprocessorDefinitions) + true + MultiThreadedDLL + true + + .\Release/normTest.pch + .\Release/ + .\Release/ + .\Release/ + Level3 + true + ProgramDatabase + Default + + + NDEBUG;%(PreprocessorDefinitions) + 0x0409 + + + iphlpapi.lib;ws2_32.lib;odbc32.lib;odbccp32.lib;%(AdditionalDependencies) + true + Windows + false + + MachineX86 + + + + + + + + {d7b0023c-8798-4918-8da0-05c9054d70b9} + false + + + + + + \ No newline at end of file diff --git a/src/common/normApi.cpp b/src/common/normApi.cpp index f09e959..84e7b4d 100644 --- a/src/common/normApi.cpp +++ b/src/common/normApi.cpp @@ -40,7 +40,7 @@ class NormInstance : public NormController void Notify(NormController::Event event, class NormSessionMgr* sessionMgr, class NormSession* session, - class NormSenderNode* sender, + class NormNode* node, class NormObject* object); bool Startup(bool priorityBoost = false); @@ -68,10 +68,13 @@ class NormInstance : public NormController bool GetNextEvent(NormEvent* theEvent); bool SetCacheDirectory(const char* cachePath); + void ReleasePreviousEvent(); + bool NotifyQueueIsEmpty() const {return notify_queue.IsEmpty();} void PurgeSessionNotifications(NormSessionHandle sessionHandle); + void PurgeNodeNotifications(NormNodeHandle nodeHandle); void PurgeObjectNotifications(NormObjectHandle objectHandle); void PurgeNotifications(NormSessionHandle sessionHandle, NormEventType eventType); @@ -96,7 +99,7 @@ class NormInstance : public NormController static NormInstance* GetInstanceFromNode(NormNodeHandle nodeHandle) { if (NORM_NODE_INVALID == nodeHandle) return ((NormInstance*)NULL); - NormSession& session = ((NormSenderNode*)nodeHandle)->GetSession(); + NormSession& session = ((NormNode*)nodeHandle)->GetSession(); return static_cast(session.GetSessionMgr().GetController()); } static NormInstance* GetInstanceFromObject(NormObjectHandle objectHandle) @@ -158,6 +161,17 @@ class NormInstance : public NormController NormSessionMgr session_mgr; private: + void ResetNotificationEvent() + { +#ifdef WIN32 + if (0 == ResetEvent(notify_event)) + PLOG(PL_ERROR, "NormInstance::GetNextEvent() ResetEvent error: %s\n", GetErrorString()); +#else + char byte[32]; + while (read(notify_fd[0], byte, 32) > 0); // TBD - error check +#endif // if/else WIN32/UNIX + } + Notification::Queue notify_pool; Notification::Queue notify_queue; Notification* previous_notification; @@ -248,7 +262,7 @@ bool NormInstance::SetCacheDirectory(const char* cachePath) void NormInstance::Notify(NormController::Event event, class NormSessionMgr* sessionMgr, class NormSession* session, - class NormSenderNode* sender, + class NormNode* node, class NormObject* object) { // (TBD) set a limit on how many pending notifications @@ -389,13 +403,13 @@ void NormInstance::Notify(NormController::Event event, // "Retain" any valid "object" or "sender" handles for API access if (NORM_OBJECT_INVALID != object) ((NormObject*)object)->Retain(); - else if (NORM_NODE_INVALID != sender) - ((NormSenderNode*)sender)->Retain(); + else if (NORM_NODE_INVALID != node) + ((NormNode*)node)->Retain(); bool doNotify = notify_queue.IsEmpty(); n->event.type = (NormEventType)event; n->event.session = session; - n->event.sender = sender; + n->event.sender = node; n->event.object = object; notify_queue.Append(n); @@ -422,6 +436,7 @@ void NormInstance::Notify(NormController::Event event, } } // end NormInstance::Notify() +// Purge any notifications associated with a specific object void NormInstance::PurgeObjectNotifications(NormObjectHandle objectHandle) { if (NORM_OBJECT_INVALID == objectHandle) return; @@ -449,17 +464,28 @@ void NormInstance::PurgeObjectNotifications(NormObjectHandle objectHandle) next = next->GetNext(); } } + if ((NULL != previous_notification) && (objectHandle == previous_notification->event.object)) + { + // "Release" any previously-retained object or node handle + ((NormObject*)(previous_notification->event.object))->Release(); + notify_pool.Append(previous_notification); + previous_notification = NULL; + } // TBD - check if event queue is emptied and reset event/fd } // end NormInstance::PurgeObjectNotifications() -void NormInstance::PurgeSessionNotifications(NormSessionHandle sessionHandle) +// Purge any notifications associated with a specific object +void NormInstance::PurgeNodeNotifications(NormNodeHandle nodeHandle) { + if (NORM_NODE_INVALID == nodeHandle) return; Notification* prev = NULL; Notification* next = notify_queue.GetHead(); - while (NULL != next) + while (next) { - if (next->event.session == sessionHandle) + if (nodeHandle == next->event.sender) { + // "Release" the previously-retained object handle + ((NormNode*)nodeHandle)->Release(); // Remove this notification from queue and return to pool Notification* current = next; next = next->GetNext(); @@ -471,16 +497,70 @@ void NormInstance::PurgeSessionNotifications(NormSessionHandle sessionHandle) notify_pool.Append(current); } else + { + prev = next; + next = next->GetNext(); + } + } + if ((NULL != previous_notification) && (nodeHandle == previous_notification->event.sender)) + { + // "Release" any previously-retained object or node handle + if (NORM_OBJECT_INVALID != previous_notification->event.object) + ((NormObject*)(previous_notification->event.object))->Release(); + else if (NORM_NODE_INVALID != previous_notification->event.sender) + ((NormNode*)(previous_notification->event.sender))->Release(); + notify_pool.Append(previous_notification); + previous_notification = NULL; + } + if (notify_queue.IsEmpty()) ResetNotificationEvent(); +} // end NormInstance::PurgeNodeNotifications() + +void NormInstance::PurgeSessionNotifications(NormSessionHandle sessionHandle) +{ + if (NORM_SESSION_INVALID == sessionHandle) return; + Notification* prev = NULL; + Notification* next = notify_queue.GetHead(); + while (NULL != next) + { + if (next->event.session == sessionHandle) + { + // Remove this notification from queue and return to pool + Notification* current = next; + next = next->GetNext(); + if (NULL != prev) + prev->Append(next); + else + notify_queue.RemoveHead(); + if (NULL == next) notify_queue.SetTail(prev); + if (NORM_OBJECT_INVALID != current->event.object) + ((NormObject*)current->event.object)->Release(); + else if (NORM_NODE_INVALID != current->event.sender) + ((NormNode*)current->event.sender)->Release(); + notify_pool.Append(current); + } + else { prev = next; next = next->GetNext(); } } - // TBD - check if event queue is emptied and reset event/fd + if ((NULL != previous_notification) && (sessionHandle == previous_notification->event.session)) + { + // "Release" any previously-retained object or node handle + if (NORM_OBJECT_INVALID != previous_notification->event.object) + ((NormObject*)(previous_notification->event.object))->Release(); + else if (NORM_NODE_INVALID != previous_notification->event.sender) + ((NormNode*)(previous_notification->event.sender))->Release(); + notify_pool.Append(previous_notification); + previous_notification = NULL; + } + if (notify_queue.IsEmpty()) ResetNotificationEvent(); } // end NormInstance::PurgeSessionNotifications() +// Purges notifications of a specific type for a specific session void NormInstance::PurgeNotifications(NormSessionHandle sessionHandle, NormEventType eventType) { + if (NORM_SESSION_INVALID == sessionHandle) return; Notification* prev = NULL; Notification* next = notify_queue.GetHead(); while (next) @@ -496,6 +576,10 @@ void NormInstance::PurgeNotifications(NormSessionHandle sessionHandle, NormEvent else notify_queue.RemoveHead(); if (NULL == next) notify_queue.SetTail(prev); + if (NORM_OBJECT_INVALID != current->event.object) + ((NormObject*)current->event.object)->Release(); + else if (NORM_NODE_INVALID != current->event.sender) + ((NormNode*)current->event.sender)->Release(); notify_pool.Append(current); } else @@ -504,7 +588,7 @@ void NormInstance::PurgeNotifications(NormSessionHandle sessionHandle, NormEvent next = next->GetNext(); } } - // TBD - check if event queue is emptied and reset event/fd + if (notify_queue.IsEmpty()) ResetNotificationEvent(); } // end NormInstance::PurgeNotifications() // NormInstance::dispatcher MUST be suspended _before_ calling this @@ -517,7 +601,7 @@ bool NormInstance::GetNextEvent(NormEvent* theEvent) if (NORM_OBJECT_INVALID != previous_notification->event.object) ((NormObject*)(previous_notification->event.object))->Release(); else if (NORM_NODE_INVALID != previous_notification->event.sender) - ((NormSenderNode*)(previous_notification->event.sender))->Release(); + ((NormNode*)(previous_notification->event.sender))->Release(); notify_pool.Append(previous_notification); previous_notification = NULL; } @@ -556,23 +640,17 @@ bool NormInstance::GetNextEvent(NormEvent* theEvent) else if (NULL != theEvent) { theEvent->type = NORM_EVENT_INVALID; - theEvent->session = NORM_SESSION_INVALID; - theEvent->sender = NORM_SESSION_INVALID; - theEvent->object = NORM_SESSION_INVALID; - } - if (notify_queue.IsEmpty()) - { -#ifdef WIN32 - if (0 == ResetEvent(notify_event)) - PLOG(PL_ERROR, "NormInstance::GetNextEvent() ResetEvent error: %s\n", GetErrorString()); -#else - char byte[32]; - while (read(notify_fd[0], byte, 32) > 0); // TBD - error check -#endif // if/else WIN32/UNIX + theEvent->session = NORM_SESSION_INVALID; + theEvent->sender = NORM_NODE_INVALID; + theEvent->object = NORM_OBJECT_INVALID; } + if (notify_queue.IsEmpty()) + ResetNotificationEvent(); return (NULL != n); } // end NormInstance::GetNextEvent() + + bool NormInstance::WaitForEvent() { if (!dispatcher.IsThreaded()) @@ -640,6 +718,35 @@ bool NormInstance::Startup(bool priorityBoost) return dispatcher.StartThread(priorityBoost); } // end NormInstance::Startup() + + +void NormInstance::ReleasePreviousEvent() +{ + // Garbage collect our "previous_notification" + if (NULL != previous_notification) + { + // Release any previously-retained object or node handles + if (NORM_OBJECT_INVALID != previous_notification->event.object) + ((NormObject*)(previous_notification->event.object))->Release(); + else if (NORM_NODE_INVALID != previous_notification->event.sender) + ((NormNode*)(previous_notification->event.sender))->Release(); + notify_pool.Append(previous_notification); + previous_notification = NULL; + } +} // end NormInstance::ReleasePreviousEvent() + +NORM_API_LINKAGE +void NormReleasePreviousEvent(NormInstanceHandle instanceHandle) +{ + NormInstance* instance = (NormInstance*)instanceHandle; + if (instance && instance->dispatcher.SuspendThread()) + { + instance->ReleasePreviousEvent(); + instance->dispatcher.ResumeThread(); + } +} // end NormReleasePreviousEvent() + + void NormInstance::Shutdown() { dispatcher.Stop(); @@ -670,7 +777,7 @@ void NormInstance::Shutdown() if (NORM_OBJECT_INVALID != previous_notification->event.object) ((NormObject*)(previous_notification->event.object))->Release(); else if (NORM_NODE_INVALID != previous_notification->event.sender) - ((NormSenderNode*)(previous_notification->event.sender))->Release(); + ((NormNode*)(previous_notification->event.sender))->Release(); notify_pool.Append(previous_notification); previous_notification = NULL; } @@ -699,7 +806,7 @@ void NormInstance::Shutdown() if (NORM_OBJECT_INVALID != n->event.object) ((NormObject*)(n->event.object))->Release(); else if (NORM_NODE_INVALID != n->event.sender) - ((NormSenderNode*)(n->event.sender))->Release(); + ((NormNode*)(n->event.sender))->Release(); delete n; } notify_pool.Destroy(); @@ -838,8 +945,8 @@ bool NormGetNextEvent(NormInstanceHandle instanceHandle, NormEvent* theEvent, bo if (!instance->WaitForEvent()) { // Indication that NormInstance is dead - // TBD - how do we inform app although this shouldn't - // happen unless the app destroys the "instance" + // TBD - how do we inform app although this shouldn't + // happen unless the app destroys the "instance" return false; } // re-suspend thread after wait @@ -857,6 +964,7 @@ bool NormGetNextEvent(NormInstanceHandle instanceHandle, NormEvent* theEvent, bo NORM_API_LINKAGE bool NormIsUnicastAddress(const char* address) { + // TBD - is this really a thread-safe thing to do? ProtoAddress addr; if ((NULL != address) && addr.ResolveFromString(address)) return addr.IsUnicast(); @@ -873,11 +981,13 @@ NormSessionHandle NormCreateSession(NormInstanceHandle instanceHandle, { // (TBD) wrap this with SuspendThread/ResumeThread ??? NormInstance* instance = (NormInstance*)instanceHandle; - if (instance) + if (instance && instance->dispatcher.SuspendThread()) { NormSession* session = instance->session_mgr.NewSession(sessionAddr, sessionPort, localNodeId); - if (session) return ((NormSessionHandle)session); + instance->dispatcher.ResumeThread(); + if (session) + return ((NormSessionHandle)session); } return NORM_SESSION_INVALID; } // end NormCreateSession() @@ -886,34 +996,35 @@ NORM_API_LINKAGE void NormDestroySession(NormSessionHandle sessionHandle) { NormInstance* instance = NormInstance::GetInstanceFromSession(sessionHandle); - if (instance) - { - if (instance->dispatcher.SuspendThread()) - { - NormSession* session = (NormSession*)sessionHandle; - if (NULL != session) - { - session->Close(); - session->GetSessionMgr().DeleteSession(session); - instance->PurgeSessionNotifications(sessionHandle); - } - instance->dispatcher.ResumeThread(); + if (instance && instance->dispatcher.SuspendThread()) + { + NormSession* session = (NormSession*)sessionHandle; + if (NULL != session) + { + session->Close(); + session->GetSessionMgr().DeleteSession(session); + instance->PurgeSessionNotifications(sessionHandle); } + instance->dispatcher.ResumeThread(); } } // end NormDestroySession() +NORM_API_LINKAGE +NormInstanceHandle NormGetInstance(NormSessionHandle sessionHandle) +{ + + return (NormInstanceHandle)NormInstance::GetInstanceFromSession(sessionHandle); +} // end NormGetIntance() + NORM_API_LINKAGE void NormSetUserData(NormSessionHandle sessionHandle, const void* userData) { NormInstance* instance = NormInstance::GetInstanceFromSession(sessionHandle); - if (instance) - { - if (instance->dispatcher.SuspendThread()) - { - NormSession* session = (NormSession*)sessionHandle; - if (session) session->SetUserData(userData); - instance->dispatcher.ResumeThread(); - } + if (instance && instance->dispatcher.SuspendThread()) + { + NormSession* session = (NormSession*)sessionHandle; + if (session) session->SetUserData(userData); + instance->dispatcher.ResumeThread(); } } // end NormSetUserData() @@ -935,6 +1046,40 @@ const void* NormGetUserData(NormSessionHandle sessionHandle) return userData; } // end NormGetUserData() + +NORM_API_LINKAGE +void NormSetUserTimer(NormSessionHandle sessionHandle, double seconds) +{ + NormInstance* instance = NormInstance::GetInstanceFromSession(sessionHandle); + if (instance) + { + if (instance->dispatcher.SuspendThread()) + { + NormSession* session = (NormSession*)sessionHandle; + if (session) session->SetUserTimer(seconds); + instance->PurgeNotifications(sessionHandle, NORM_USER_TIMEOUT); + instance->dispatcher.ResumeThread(); + } + } +} // end NormSetUserTimer() + +NORM_API_LINKAGE +void NormCancelUserTimer(NormSessionHandle sessionHandle) +{ + NormInstance* instance = NormInstance::GetInstanceFromSession(sessionHandle); + if (instance) + { + if (instance->dispatcher.SuspendThread()) + { + NormSession* session = (NormSession*)sessionHandle; + if (session) session->SetUserTimer(-1.0); // interval less than zero cancels timer + instance->PurgeNotifications(sessionHandle, NORM_USER_TIMEOUT); + instance->dispatcher.ResumeThread(); + } + } +} // end NormCancelUserTimer() + + NORM_API_LINKAGE NormNodeId NormGetLocalNodeId(NormSessionHandle sessionHandle) { @@ -945,6 +1090,17 @@ NormNodeId NormGetLocalNodeId(NormSessionHandle sessionHandle) return NORM_NODE_NONE; } // end NormGetLocalNodeId() +NORM_API_LINKAGE +UINT16 NormGetRxPort(NormSessionHandle sessionHandle) +{ + NormSession* session = (NormSession*)sessionHandle; + if (NULL != session) + return session->GetRxPort(); + else + return 0; +} // end NormGetRxPort() + + NORM_API_LINKAGE bool NormSetTxPort(NormSessionHandle sessionHandle, UINT16 txPort, @@ -993,7 +1149,8 @@ void NormSetTxOnly(NormSessionHandle sessionHandle, NORM_API_LINKAGE bool NormChangeDestination(NormSessionHandle sessionHandle, const char* sessionAddress, - UINT16 sessionPort) + UINT16 sessionPort, + bool connectToSessionAddress) { // First, see if we can make a valid ProtoAddress ProtoAddress dest; @@ -1004,7 +1161,12 @@ bool NormChangeDestination(NormSessionHandle sessionHandle, if (instance && instance->dispatcher.SuspendThread()) { NormSession* session = (NormSession*)sessionHandle; - if (session) session->SetAddress(dest); + if (session) + { + session->SetAddress(dest); + if (connectToSessionAddress) + session->SetTxOnly(session->GetTxOnly(), true); + } instance->dispatcher.ResumeThread(); } return true; @@ -1029,16 +1191,6 @@ void NormSetRxPortReuse(NormSessionHandle sessionHandle, } } // end NormSetRxPortReuse() -NORM_API_LINKAGE -UINT16 NormGetRxPort(NormSessionHandle sessionHandle) -{ - NormSession* session = (NormSession*)sessionHandle; - if (NULL != session) - return session->GetRxPort(); - else - return 0; -} // end NormGetRxPort() - NORM_API_LINKAGE void NormSetEcnSupport(NormSessionHandle sessionHandle, bool ecnEnable, bool ignoreLoss, bool tolerateLoss) @@ -1074,6 +1226,25 @@ bool NormSetMulticastInterface(NormSessionHandle sessionHandle, return result; } // end NormSetMulticastInterface() +NORM_API_LINKAGE +bool NormSetSSM(NormSessionHandle sessionHandle, + const char* sourceAddress) +{ + bool result = false; + NormInstance* instance = NormInstance::GetInstanceFromSession(sessionHandle); + if (NULL != instance) + { + if (instance->dispatcher.SuspendThread()) + { + NormSession* session = (NormSession*)sessionHandle; + if (session) + result = session->SetSSM(sourceAddress); + instance->dispatcher.ResumeThread(); + } + } + return result; +} // end NormSetSSM() + NORM_API_LINKAGE bool NormSetTTL(NormSessionHandle sessionHandle, unsigned char ttl) @@ -1125,6 +1296,16 @@ bool NormSetLoopback(NormSessionHandle sessionHandle, bool state) } // end NormSetLoopback() +NORM_API_LINKAGE +bool NormSetMulticastLoopback(NormSessionHandle sessionHandle, bool state) +{ + NormSession* session = (NormSession*)sessionHandle; + if (session) + return session->SetMulticastLoopback(state); + else + return false; +} // end NormSetLoopback() + NORM_API_LINKAGE bool NormSetFragmentation(NormSessionHandle sessionHandle, bool state) { @@ -1263,10 +1444,10 @@ NormSessionId NormGetRandomSessionId() NORM_API_LINKAGE bool NormStartSender(NormSessionHandle sessionHandle, NormSessionId sessionId, - UINT32 bufferSpace, - UINT16 segmentSize, - unsigned char numData, - unsigned char numParity) + UINT32 bufferSpace, + UINT16 segmentSize, + UINT16 numData, + UINT16 numParity) { bool result = false; NormInstance* instance = NormInstance::GetInstanceFromSession(sessionHandle); @@ -1727,6 +1908,8 @@ bool NormSetWatermark(NormSessionHandle sessionHandle, NormObject* obj = (NormObject*)objectHandle; if (session && obj) { + // Purge any existing to NORM_TX_WATERMARK_COMPLETED notification to be safe + instance->PurgeNotifications(sessionHandle, NORM_TX_WATERMARK_COMPLETED); // (segmentId doesn't matter for non-stream) if (obj->IsStream()) { @@ -1791,7 +1974,7 @@ bool NormAddAckingNode(NormSessionHandle sessionHandle, { NormSession* session = (NormSession*)sessionHandle; if (session) - result = session->SenderAddAckingNode(nodeId); + result = (NULL != session->SenderAddAckingNode(nodeId)); instance->dispatcher.ResumeThread(); } return result; @@ -1810,6 +1993,20 @@ void NormRemoveAckingNode(NormSessionHandle sessionHandle, } } // end NormRemoveAckingNode() +NORM_API_LINKAGE +NormNodeHandle NormGetAckingNodeHandle(NormSessionHandle sessionHandle, + NormNodeId nodeId) +{ + if (NORM_SESSION_INVALID != sessionHandle) + { + NormSession* session = (NormSession*)sessionHandle; + NormAckingNode* acker = session->SenderFindAckingNode(nodeId); + if (NULL != acker) + return ((NormNodeHandle)static_cast(acker)); + } + return NORM_NODE_INVALID; +} // end NormGetAckingNodeHandle() + NORM_API_LINKAGE void NormSetAutoAckingNodes(NormSessionHandle sessionHandle, NormTrackingStatus trackingStatus) @@ -1994,8 +2191,12 @@ void NormNodeSetUnicastNack(NormNodeHandle nodeHandle, bool unicastNacks) { - NormSenderNode* node = (NormSenderNode*)nodeHandle; - if (node) node->SetUnicastNacks(unicastNacks); + NormNode* node = (NormNode*)nodeHandle; + if ((NULL != node) && (NormNode::SENDER == node->GetType())) + { + NormSenderNode* sender = static_cast(node); + sender->SetUnicastNacks(unicastNacks); + } } // end NormNodeSetUnicastNack() NORM_API_LINKAGE @@ -2018,8 +2219,12 @@ NORM_API_LINKAGE void NormNodeSetNackingMode(NormNodeHandle nodeHandle, NormNackingMode nackingMode) { - NormSenderNode* node = (NormSenderNode*)nodeHandle; - if (node) node->SetDefaultNackingMode((NormObject::NackingMode)nackingMode); + NormNode* node = (NormNode*)nodeHandle; + if ((NULL != node) && (NormNode::SENDER == node->GetType())) + { + NormSenderNode* sender = static_cast(node); + sender->SetDefaultNackingMode((NormObject::NackingMode)nackingMode); + } } // end NormNodeSetNackingMode() NORM_API_LINKAGE @@ -2043,9 +2248,12 @@ NORM_API_LINKAGE void NormNodeSetRepairBoundary(NormNodeHandle nodeHandle, NormRepairBoundary repairBoundary) { - NormSenderNode* node = static_cast((NormSenderNode*)nodeHandle); - if (node) - node->SetRepairBoundary((NormSenderNode::RepairBoundary)repairBoundary); + NormNode* node = (NormNode*)nodeHandle; + if ((NULL != node) && (NormNode::SENDER == node->GetType())) + { + NormSenderNode* sender = static_cast(node); + sender->SetRepairBoundary((NormSenderNode::RepairBoundary)repairBoundary); + } } // end NormNodeSetRepairBoundary() @@ -2071,8 +2279,12 @@ void NormNodeSetRxRobustFactor(NormNodeHandle nodeHandle, NormInstance* instance = NormInstance::GetInstanceFromNode(nodeHandle); if (instance && instance->dispatcher.SuspendThread()) { - NormSenderNode* node = (NormSenderNode*)nodeHandle; - node->SetRobustFactor(robustFactor); + NormNode* node = (NormNode*)nodeHandle; + if (NormNode::SENDER == node->GetType()) + { + NormSenderNode* sender = static_cast(node); + sender->SetRobustFactor(robustFactor); + } instance->dispatcher.ResumeThread(); } } @@ -2322,9 +2534,15 @@ const char* NormDataAccessData(NormObjectHandle dataHandle) NORM_API_LINKAGE char* NormDataDetachData(NormObjectHandle dataHandle) { - NormDataObject* dataObj = - static_cast((NormObject*)dataHandle); - return dataObj->DetachData(); + char* ptr = NULL; + NormInstance* instance = NormInstance::GetInstanceFromObject(dataHandle); + if (instance && instance->dispatcher.SuspendThread()) + { + NormDataObject* dataObj = static_cast((NormObject*)dataHandle); + ptr = dataObj->DetachData(); + instance->dispatcher.ResumeThread(); + } + return ptr; } // end NormDataDetachData() NORM_API_LINKAGE @@ -2339,7 +2557,7 @@ NormNodeHandle NormObjectGetSender(NormObjectHandle objectHandle) NORM_API_LINKAGE NormNodeId NormNodeGetId(NormNodeHandle nodeHandle) { - NormSenderNode* node = (NormSenderNode*)nodeHandle; + NormNode* node = (NormNode*)nodeHandle; if (NULL != node) return node->GetId(); else @@ -2355,10 +2573,10 @@ bool NormNodeGetAddress(NormNodeHandle nodeHandle, bool result = false; if (NORM_NODE_INVALID != nodeHandle) { - NormInstance* instance = NormInstance::GetInstanceFromNode(nodeHandle); - if (instance && instance->dispatcher.SuspendThread()) + //NormInstance* instance = NormInstance::GetInstanceFromNode(nodeHandle); + //if (instance && instance->dispatcher.SuspendThread()) { - NormSenderNode* node = (NormSenderNode*)nodeHandle; + NormNode* node = (NormSenderNode*)nodeHandle; const ProtoAddress& nodeAddr = node->GetAddress(); unsigned int addrLen = nodeAddr.GetLength(); if (addrBuffer && bufferLen && (addrLen <= *bufferLen)) @@ -2372,20 +2590,45 @@ bool NormNodeGetAddress(NormNodeHandle nodeHandle, } if (bufferLen) *bufferLen = addrLen; if (port) *port = nodeAddr.GetPort(); - instance->dispatcher.ResumeThread(); + //instance->dispatcher.ResumeThread(); } } return result; -} // end NormNodeGetId() +} // end NormNodeGetAddress() + +NORM_API_LINKAGE +void NormNodeSetUserData(NormNodeHandle nodeHandle, const void* userData) +{ + if (NORM_NODE_INVALID != nodeHandle) + { + NormNode* node = (NormNode*)nodeHandle; + return node->SetUserData(userData); + } +} + +NORM_API_LINKAGE +const void* NormNodeGetUserData(NormNodeHandle nodeHandle) +{ + NormNode* node = (NormNode*)nodeHandle; + if (NULL != node) + return node->GetUserData(); + else + return NULL; +} // end NormNodeGetUserData() NORM_API_LINKAGE double NormNodeGetGrtt(NormNodeHandle nodeHandle) { - NormSenderNode* node = (NormSenderNode*)nodeHandle; - if (NULL != node) - return node->GetGrttEstimate(); + NormNode* node = (NormNode*)nodeHandle; + if ((NULL != node) && (NormNode::SENDER == node->GetType())) + { + NormSenderNode* sender = static_cast(node); + return sender->GetGrttEstimate(); + } else + { return -1.0; + } } // end NormNodeGetGrtt() NORM_API_LINKAGE @@ -2399,8 +2642,12 @@ bool NormNodeGetCommand(NormNodeHandle nodeHandle, NormInstance* instance = NormInstance::GetInstanceFromNode(nodeHandle); if (instance && instance->dispatcher.SuspendThread()) { - NormSenderNode* node = (NormSenderNode*)nodeHandle; - result = node->ReadNextCmd(cmdBuffer, cmdLength); + NormNode* node = (NormNode*)nodeHandle; + if (NormNode::SENDER == node->GetType()) + { + NormSenderNode* sender = static_cast(node); + result = sender->ReadNextCmd(cmdBuffer, cmdLength); + } instance->dispatcher.ResumeThread(); } } @@ -2415,8 +2662,14 @@ void NormNodeFreeBuffers(NormNodeHandle nodeHandle) NormInstance* instance = NormInstance::GetInstanceFromNode(nodeHandle); if (instance && instance->dispatcher.SuspendThread()) { - NormSenderNode* node = (NormSenderNode*)nodeHandle; - node->FreeBuffers(); + NormNode* node = (NormNode*)nodeHandle; + if (NormNode::SENDER == node->GetType()) + { + NormSenderNode* sender = static_cast(node); + sender->FreeBuffers(); + // Since this results in aborted objects, should we purge those object notifications? + // or let the be delivered since the app may have associate state + } instance->dispatcher.ResumeThread(); } } @@ -2430,8 +2683,14 @@ void NormNodeDelete(NormNodeHandle nodeHandle) NormInstance* instance = NormInstance::GetInstanceFromNode(nodeHandle); if (instance && instance->dispatcher.SuspendThread()) { - NormSenderNode* node = (NormSenderNode*)nodeHandle; - node->GetSession().DeleteRemoteSender(*node); + NormNode* node = (NormNode*)nodeHandle; + if (NormNode::SENDER == node->GetType()) + { + NormSenderNode* sender = static_cast(node); + sender->GetSession().DeleteRemoteSender(*sender); + } + // else if NormNode::ACKER, should we remove from acking node list??? + instance->PurgeNodeNotifications(nodeHandle); instance->dispatcher.ResumeThread(); } } @@ -2445,7 +2704,7 @@ void NormNodeRetain(NormNodeHandle nodeHandle) NormInstance* instance = NormInstance::GetInstanceFromNode(nodeHandle); if (instance && instance->dispatcher.SuspendThread()) { - ((NormSenderNode*)nodeHandle)->Retain(); + ((NormNode*)nodeHandle)->Retain(); instance->dispatcher.ResumeThread(); } } @@ -2459,7 +2718,7 @@ void NormNodeRelease(NormNodeHandle nodeHandle) NormInstance* instance = NormInstance::GetInstanceFromNode(nodeHandle); if (instance && instance->dispatcher.SuspendThread()) { - ((NormSenderNode*)nodeHandle)->Release(); + ((NormNode*)nodeHandle)->Release(); instance->dispatcher.ResumeThread(); } } diff --git a/src/common/normApp.cpp b/src/common/normApp.cpp index 72d5dab..c46eda2 100644 --- a/src/common/normApp.cpp +++ b/src/common/normApp.cpp @@ -76,7 +76,7 @@ class NormApp : public NormController, public ProtoApp virtual void Notify(NormController::Event event, class NormSessionMgr* sessionMgr, class NormSession* session, - class NormSenderNode* sender, + class NormNode* node, class NormObject* object); bool OnIntervalTimeout(ProtoTimer& theTimer); @@ -490,8 +490,9 @@ bool NormApp::OnCommand(const char* cmd, const char* val) len = strlen(buffer); len = (len > 8191) ? 8191 : len; buffer[len++] = '\0'; - if (!control_pipe.Send(buffer, (unsigned int&)len)) - { + unsigned int numBytes = (unsigned int)len; + if (!control_pipe.Send(buffer, numBytes)) + { PLOG(PL_FATAL, "NormApp::OnCommand() error sending command to remote instance\n"); return false; } @@ -1494,7 +1495,7 @@ void NormApp::OnInputReady() void NormApp::Notify(NormController::Event event, class NormSessionMgr* sessionMgr, class NormSession* session, - class NormSenderNode* sender, + class NormNode* sender, class NormObject* object) { switch (event) @@ -1558,7 +1559,8 @@ void NormApp::Notify(NormController::Event event, case REMOTE_SENDER_INACTIVE: PLOG(PL_DEBUG, "NormApp::Notify(REMOTE_SENDER_INACTIVE) ...\n"); - if (!rx_persistent) sender->FreeBuffers(); + if (!rx_persistent) + static_cast(sender)->FreeBuffers(); break; diff --git a/src/common/normEncoderRS16.cpp b/src/common/normEncoderRS16.cpp index d474bfa..9788452 100644 --- a/src/common/normEncoderRS16.cpp +++ b/src/common/normEncoderRS16.cpp @@ -764,13 +764,13 @@ int NormDecoderRS16::Decode(char** vectorList, unsigned int numData, unsigned i bool NormDecoderRS16::InvertDecodingMatrix() { gf* src = (gf*)dec_matrix; - int k = ndata; + unsigned int k = ndata; memset(inv_id_row, 0, k*sizeof(gf)); // inv_pivt marks elements already used as pivots. memset(inv_pivt, 0, k*sizeof(unsigned int)); - for (int col = 0; col < k ; col++) + for (unsigned int col = 0; col < k ; col++) { /* * Zeroing column 'col', look for a non-zero element. @@ -788,7 +788,7 @@ bool NormDecoderRS16::InvertDecodingMatrix() { if (inv_pivt[row] != 1) { - for (int ix = 0 ; ix < k ; ix++) + for (unsigned int ix = 0 ; ix < k ; ix++) { if (inv_pivt[ix] == 0) { @@ -821,7 +821,7 @@ bool NormDecoderRS16::InvertDecodingMatrix() */ if (irow != icol) { - for (int ix = 0 ; ix < k ; ix++ ) + for (unsigned int ix = 0 ; ix < k ; ix++ ) SWAP(src[irow*k + ix], src[icol*k + ix], gf); } inv_ndxr[col] = irow ; @@ -841,7 +841,7 @@ bool NormDecoderRS16::InvertDecodingMatrix() */ c = inverse[ c ] ; pivotRow[icol] = 1 ; - for (int ix = 0 ; ix < k ; ix++ ) + for (unsigned int ix = 0 ; ix < k ; ix++ ) pivotRow[ix] = gf_mul(c, pivotRow[ix] ); } /* @@ -869,11 +869,11 @@ bool NormDecoderRS16::InvertDecodingMatrix() for (int col = k - 1 ; col >= 0 ; col-- ) { - if (inv_ndxr[col] < 0 || inv_ndxr[col] >= (unsigned int)k) + if (inv_ndxr[col] >= k) { PLOG(PL_ERROR, "NormDecoderRS16::InvertDecodingMatrix() error: AARGH, inv_ndxr[col] %d\n", inv_ndxr[col]); } - else if (inv_ndxc[col] <0 || inv_ndxc[col] >= (unsigned int)k) + else if (inv_ndxc[col] >= k) { PLOG(PL_ERROR, "NormDecoderRS16::InvertDecodingMatrix() error: AARGH, indxc[col] %d\n", inv_ndxc[col]); } diff --git a/src/common/normEncoderRS8.cpp b/src/common/normEncoderRS8.cpp index 3b50aad..778efba 100644 --- a/src/common/normEncoderRS8.cpp +++ b/src/common/normEncoderRS8.cpp @@ -37,7 +37,7 @@ #include "protoDebug.h" #ifdef SIMULATE -#include "normMessage.h" +#include "normMessage.h" #endif // SIMULATE /* @@ -52,7 +52,7 @@ */ #define GF_BITS 8 // 8-bit RS code -#if (GF_BITS < 2 && GF_BITS > 16) +#if (GF_BITS < 2) || (GF_BITS > 16) #error "GF_BITS must be 2 .. 16" #endif #if (GF_BITS <= 8) @@ -766,13 +766,13 @@ int NormDecoderRS8::Decode(char** vectorList, unsigned int numData, unsigned in bool NormDecoderRS8::InvertDecodingMatrix() { gf* src = (gf*)dec_matrix; - int k = ndata; + unsigned int k = ndata; memset(inv_id_row, 0, k*sizeof(gf)); // inv_pivt marks elements already used as pivots. memset(inv_pivt, 0, k*sizeof(unsigned int)); - for (int col = 0; col < k ; col++) + for (unsigned int col = 0; col < k ; col++) { /* * Zeroing column 'col', look for a non-zero element. @@ -786,11 +786,11 @@ bool NormDecoderRS8::InvertDecodingMatrix() icol = col ; goto found_piv ; } - for (int row = 0 ; row < k ; row++) + for (unsigned int row = 0 ; row < k ; row++) { if (inv_pivt[row] != 1) { - for (int ix = 0 ; ix < k ; ix++) + for (unsigned int ix = 0 ; ix < k ; ix++) { if (inv_pivt[ix] == 0) { @@ -823,7 +823,7 @@ bool NormDecoderRS8::InvertDecodingMatrix() */ if (irow != icol) { - for (int ix = 0 ; ix < k ; ix++ ) + for (unsigned int ix = 0 ; ix < k ; ix++ ) SWAP(src[irow*k + ix], src[icol*k + ix], gf); } inv_ndxr[col] = irow ; @@ -843,7 +843,7 @@ bool NormDecoderRS8::InvertDecodingMatrix() */ c = inverse[ c ] ; pivotRow[icol] = 1 ; - for (int ix = 0 ; ix < k ; ix++ ) + for (unsigned int ix = 0 ; ix < k ; ix++ ) pivotRow[ix] = gf_mul(c, pivotRow[ix] ); } /* @@ -871,17 +871,17 @@ bool NormDecoderRS8::InvertDecodingMatrix() for (int col = k - 1 ; col >= 0 ; col-- ) { - if (inv_ndxr[col] < 0 || inv_ndxr[col] >= (unsigned int)k) + if (inv_ndxr[col] >= k) { PLOG(PL_ERROR, "NormDecoderRS8::InvertDecodingMatrix() error: AARGH, inv_ndxr[col] %d\n", inv_ndxr[col]); } - else if (inv_ndxc[col] <0 || inv_ndxc[col] >= (unsigned int)k) + else if (inv_ndxc[col] >= k) { PLOG(PL_ERROR, "NormDecoderRS8::InvertDecodingMatrix() error: AARGH, indxc[col] %d\n", inv_ndxc[col]); } else if (inv_ndxr[col] != inv_ndxc[col] ) { - for (int row = 0 ; row < k ; row++ ) + for (unsigned int row = 0 ; row < k ; row++ ) SWAP( src[row*k + inv_ndxr[col]], src[row*k + inv_ndxc[col]], gf) ; } } diff --git a/src/common/normNode.cpp b/src/common/normNode.cpp index 045b0f6..daad585 100644 --- a/src/common/normNode.cpp +++ b/src/common/normNode.cpp @@ -5,8 +5,8 @@ #include "normEncoderRS8.h" // 8-bit Reed-Solomon encoder of RFC 5510 #include "normEncoderRS16.h" // 16-bit Reed-Solomon encoder of RFC 5510 -NormNode::NormNode(class NormSession& theSession, NormNodeId nodeId) - : session(theSession), id(nodeId), reference_count(1), +NormNode::NormNode(Type nodeType, class NormSession& theSession, NormNodeId nodeId) + : session(theSession), node_type(nodeType), id(nodeId), reference_count(1), user_data(NULL), parent(NULL), right(NULL), left(NULL) { @@ -14,8 +14,10 @@ NormNode::NormNode(class NormSession& theSession, NormNodeId nodeId) NormNode::~NormNode() { + //TRACE("NormNode %lu dtor ...\n", (unsigned long)id); } + void NormNode::Retain() { reference_count++; @@ -40,9 +42,8 @@ NormNode::Accumulator::Accumulator() } - NormCCNode::NormCCNode(class NormSession& theSession, NormNodeId nodeId) - : NormNode(theSession, nodeId) + : NormNode(CC_NODE, theSession, nodeId) { } @@ -65,11 +66,11 @@ const double NormSenderNode::DEFAULT_NOMINAL_INTERVAL = 2*NormSession::DEFAULT_G const double NormSenderNode::ACTIVITY_INTERVAL_MIN = 1.0; // 1 second min activity timeout NormSenderNode::NormSenderNode(class NormSession& theSession, NormNodeId nodeId) - : NormNode(theSession, nodeId), instance_id(0), robust_factor(session.GetRxRobustFactor()), + : NormNode(SENDER, theSession, nodeId), instance_id(0), robust_factor(session.GetRxRobustFactor()), synchronized(false), sync_id(0), is_open(false), segment_size(0), fec_m(0), ndata(0), nparity(0), repair_boundary(BLOCK_BOUNDARY), decoder(NULL), erasure_loc(NULL), - retrieval_loc(NULL), retrieval_pool(NULL), + retrieval_loc(NULL), retrieval_pool(NULL), ack_pending(false), cc_sequence(0), cc_enable(false), cc_feedback_needed(false), cc_rate(0.0), rtt_confirmed(false), is_clr(false), is_plr(false), slow_start(true), send_rate(0.0), recv_rate(0.0), recv_rate_prev(0.0), @@ -160,6 +161,7 @@ void NormSenderNode::Close() if (activity_timer.IsActive()) activity_timer.Deactivate(); if (repair_timer.IsActive()) repair_timer.Deactivate(); if (cc_timer.IsActive()) cc_timer.Deactivate(); + if (ack_timer.IsActive()) ack_timer.Deactivate(); FreeBuffers(); // Delete any command buffers from cmd_buffer queue @@ -566,7 +568,7 @@ void NormSenderNode::HandleCommand(const struct timeval& currentTime, } // 1) Sync to squelch (discards all objects prior to squelch objectId) NormObjectId objectId = squelch.GetObjectId(); - Sync(objectId); + Sync(objectId); // 2) Prune stream object if applicable NormObject* obj = rx_table.Find(objectId); if ((NULL != obj) && (NormObject::STREAM == obj->GetType())) @@ -638,7 +640,6 @@ void NormSenderNode::HandleCommand(const struct timeval& currentTime, is_clr = is_plr = false; } double maxBackoff; - if (is_clr || is_plr || !session.Address().IsMulticast()) { // Respond immediately (i.e., no backoff, holdoff etc) @@ -757,6 +758,7 @@ void NormSenderNode::HandleCommand(const struct timeval& currentTime, { double ackBackoff = session.Address().IsMulticast() ? UniformRand(grtt_estimate) : 0.0; ack_timer.SetInterval(ackBackoff); + ack_pending = true; session.ActivateTimer(ack_timer); } break; // no pending repairs, skip regular "RepairCheck" @@ -1546,9 +1548,7 @@ void NormSenderNode::HandleObjectMessage(const NormObjectMsg& msg) break; } // end switch(status) - - - if (obj) + if (NULL != obj) { obj->HandleObjectMessage(msg, msgType, blockId, segmentId); @@ -1742,11 +1742,9 @@ NormSenderNode::ObjectStatus NormSenderNode::UpdateSyncStatus(const NormObjectId { NormObjectId lastPending(65535); GetLastPending(lastPending); - TRACE("lp:%hu\n", (UINT16)lastPending); if (syncId > lastPending) { UINT16 delta = syncId - lastPending; - TRACE("SYNC DELTA = %d\n", delta); if (delta < max_pending_range) { syncId -= (max_pending_range - 1); @@ -2179,7 +2177,6 @@ bool NormSenderNode::OnRepairTimeout(ProtoTimer& /*theTimer*/) default: break; } - if (NULL != obj) { if (obj->IsPending(nextId != max_pending_object)) @@ -2401,8 +2398,8 @@ bool NormSenderNode::OnActivityTimeout(ProtoTimer& /*theTimer*/) } else if (0 == activity_timer.GetRepeatCount()) { - // Serve completely inactive? - PLOG(PL_ERROR, "NormSenderNode::OnActivityTimeout() node>%lu sender>%lu gone inactive?\n", + // Remote sender completely inactive? + PLOG(PL_INFO, "NormSenderNode::OnActivityTimeout() node>%lu sender>%lu gone inactive?\n", LocalNodeId(), GetId()); //FreeBuffers(); This now needs to be done by the app as of norm version 1.4b3 session.Notify(NormController::REMOTE_SENDER_INACTIVE, this, NULL); @@ -2419,7 +2416,7 @@ bool NormSenderNode::OnActivityTimeout(ProtoTimer& /*theTimer*/) NormObject* objMax = rx_table.Find(max_pending_object); if (NULL != objMax) { - /*NormSegmentId segMax = objMax->GetMaxPendingSegmentId(); + NormSegmentId segMax = objMax->GetMaxPendingSegmentId(); if (0 != segMax) RepairCheck(NormObject::THRU_SEGMENT, max_pending_object, @@ -2429,10 +2426,14 @@ bool NormSenderNode::OnActivityTimeout(ProtoTimer& /*theTimer*/) RepairCheck(NormObject::TO_BLOCK, max_pending_object, objMax->GetMaxPendingBlockId(), - 0);*/ - // Let's try this instead - RepairCheck(NormObject::THRU_OBJECT, // (TBD) thru object??? - max_pending_object, 0, 0); + 0); + + // The above has been reinstated because the alternative "THRU_OBJECT" here + // causes gratuitous NACKing when the sender goes IDLE .. + + // Or we could do this instead (possibly some unnecessary NACKing for NORM_OBJECT_STREAM will occur here) + //RepairCheck(NormObject::THRU_OBJECT, // (TBD) thru object??? + // max_pending_object, 0, 0); // (TBD) What should we really do here? Our current NormNode::RepairCheck() and // NormObject::ReceiverRepairCheck() methods update the "max_pending" indices @@ -2445,7 +2446,12 @@ bool NormSenderNode::OnActivityTimeout(ProtoTimer& /*theTimer*/) // I guess the activity timeout NACK isn't perfect ... but could help some // so we leave it as it is for the moment ("THRU_OBJECT") ... perhaps we could // add a parameter so NormObject::ReceiverRepairCheck() doesn't update its - // "max_pending" indices - or would this break NACK building + // "max_pending" indices - or would this break NACK building? + + // Maybe we should do THRU_OBJECT when the remote sender is fully inactive as + // opposed to this inactivity timeout that only pays attend to NORM_DATA. I.e., + // do the above refined RepairCheck() when we still have NORM_CMD activity but + // no NORM_DATA activity??? We'd still have potentially a lot of EOT NACKing } else { @@ -2455,7 +2461,7 @@ bool NormSenderNode::OnActivityTimeout(ProtoTimer& /*theTimer*/) // max_pending_object, 0, 0); } } - // We manually managed the "repeat_count" here to avoid the + // We manually manage the "repeat_count" here to avoid the // case where "bursty" receiver scheduling may lead to false // inactivity indication int repeatCount = activity_timer.GetRepeatCount(); @@ -2572,6 +2578,14 @@ void NormSenderNode::AttachCCFeedback(NormAckMsg& ack) bool NormSenderNode::OnCCTimeout(ProtoTimer& /*theTimer*/) { // Build and send NORM_ACK(CC) + if (ack_pending && (1 == cc_timer.GetRepeatCount())) + { + // Send ACK flush right away (CC feedback is included + if (ack_timer.IsActive()) ack_timer.Deactivate(); + if (cc_timer.IsActive()) cc_timer.Deactivate(); // will be reactivated if needed + OnAckTimeout(ack_timer); + return false; + } switch (cc_timer.GetRepeatCount()) { case 0: @@ -2601,23 +2615,31 @@ bool NormSenderNode::OnCCTimeout(ProtoTimer& /*theTimer*/) ack->SetDestination(GetAddress()); else ack->SetDestination(session.Address()); - session.SendMessage(*ack); + bool success = session.SendMessage(*ack); session.ReturnMessageToPool(ack); - cc_feedback_needed = false; - - // Begin cc_timer "holdoff" phase - if (!is_clr && !is_plr && session.Address().IsMulticast()) + if (success) { - cc_timer.SetInterval(grtt_estimate*backoff_factor); - return true; + cc_feedback_needed = false; + // Begin cc_timer "holdoff" phase + if (!is_clr && !is_plr && session.Address().IsMulticast()) + { + cc_timer.SetInterval(grtt_estimate*backoff_factor); + } + else if (cc_timer.IsActive()) + { + cc_timer.Deactivate(); + return false; + } } - else if (cc_timer.IsActive()) + else { - cc_timer.Deactivate(); + // TBD - queue ack so it gets send retry? + PLOG(PL_ERROR, "NormSenderNode::OnCCTimeout() error: SendMessage(ack) failure\n"); + if (cc_timer.IsActive()) cc_timer.Deactivate(); + return false; } break; } - default: // Should never occur ASSERT(0); @@ -2630,7 +2652,7 @@ bool NormSenderNode::OnAckTimeout(ProtoTimer& /*theTimer*/) { // Build and send NORM_ACK(FLUSH) NormAckFlushMsg* ack = (NormAckFlushMsg*)session.GetMessageFromPool(); - if (ack) + if (NULL != ack) { ack->Init(); ack->SetSenderId(GetId()); @@ -2657,24 +2679,31 @@ bool NormSenderNode::OnAckTimeout(ProtoTimer& /*theTimer*/) ack->SetDestination(session.Address()); // Don't rate limit feedback messages - session.SendMessage(*ack); - session.ReturnMessageToPool(ack); - cc_feedback_needed = false; - if (cc_enable && !is_clr && !is_plr && session.Address().IsMulticast()) + if (session.SendMessage(*ack)) + { + ack_pending = false; + cc_feedback_needed = false; + if (cc_enable && !is_clr && !is_plr && session.Address().IsMulticast()) + { + // Install cc feedback holdoff + cc_timer.SetInterval(grtt_estimate*backoff_factor); + if (cc_timer.IsActive()) + cc_timer.Reschedule(); + else + session.ActivateTimer(cc_timer); + cc_timer.DecrementRepeatCount(); // put timer into "holdoff" phase + } + else if (cc_timer.IsActive()) + { + cc_timer.Deactivate(); + } + } + else { - // Install cc feedback holdoff - cc_timer.SetInterval(grtt_estimate*backoff_factor); - if (cc_timer.IsActive()) - cc_timer.Reschedule(); - else - session.ActivateTimer(cc_timer); - cc_timer.DecrementRepeatCount(); // put timer into "holdoff" phase - } - else if (cc_timer.IsActive()) - { - cc_timer.Deactivate(); - return false; + // TBD - should we queue the message so it can get a send retry? + PLOG(PL_ERROR, "NormSenderNode::OnAckTimeout() error: SendMessage(ack) failure\n"); } + session.ReturnMessageToPool(ack); } else { @@ -2685,7 +2714,7 @@ bool NormSenderNode::OnAckTimeout(ProtoTimer& /*theTimer*/) NormAckingNode::NormAckingNode(class NormSession& theSession, NormNodeId nodeId) - : NormNode(theSession, nodeId), ack_received(false), req_count(theSession.GetTxRobustFactor()) + : NormNode(ACKER, theSession, nodeId), ack_received(false), req_count(theSession.GetTxRobustFactor()) { } diff --git a/src/common/normObject.cpp b/src/common/normObject.cpp index 211bfd0..6718d21 100644 --- a/src/common/normObject.cpp +++ b/src/common/normObject.cpp @@ -47,6 +47,10 @@ void NormObject::Retain() void NormObject::Release() { + + //if ((NULL != sender) && (reference_count == 1)) + // TRACE("NormObject final release node>%lu object>%hu\n", (unsigned long)sender->GetId(), (unsigned short)transport_id); + if (sender) sender->Release(); if (reference_count) { @@ -235,7 +239,7 @@ void NormObject::Close() NormObjectSize NormObject::GetBytesPending() const { NormBlockId nextId; - if (GetFirstPending(nextId)) + if (!IsStream() && GetFirstPending(nextId)) { NormObjectSize largeBlockBytes = NormObjectSize(large_block_size) * NormObjectSize(segment_size); @@ -264,7 +268,7 @@ NormObjectSize NormObject::GetBytesPending() const { return NormObjectSize(0); } -} // end NormObject::GetBytesCompleted() +} // end NormObject::GetBytesPending() // Used by sender bool NormObject::HandleInfoRequest(bool holdoff) @@ -824,7 +828,7 @@ bool NormObject::ReceiverRepairCheck(CheckLevel level, if (segmentId >= max_pending_segment) max_pending_segment = segmentId + 1; } - if (blockId == final_block_id) + if (!IsStream() && (blockId == final_block_id)) { unsigned int finalSegment = GetBlockSize(blockId) - 1; if (finalSegment <= segmentId) @@ -858,7 +862,6 @@ bool NormObject::ReceiverRepairCheck(CheckLevel level, } else { - NormBlockId firstPending; if (GetFirstPending(firstPending)) { @@ -901,7 +904,7 @@ bool NormObject::ReceiverRepairCheck(CheckLevel level, max_pending_block = blockId; max_pending_segment = GetBlockSize(blockId); } - if (blockId == final_block_id) + if (!IsStream() && (blockId == final_block_id)) thruObject = true; if (timerActive) { @@ -1178,7 +1181,7 @@ bool NormObject::AppendRepairRequest(NormNackMsg& nack, return requestAppended; } } - if (flush || (nextId != max_pending_block)) + if (flush || (nextId != max_pending_block)) { block->AppendRepairRequest(nack, fec_id, fec_m, numData, nparity, transport_id, pending_info, segment_size); // (TBD) error check @@ -1192,10 +1195,10 @@ bool NormObject::AppendRepairRequest(NormNackMsg& nack, block->AppendRepairRequest(nack, fec_id, fec_m, numData, nparity, transport_id, pending_info, segment_size); // (TBD) error check } - requestAppended = true; + requestAppended = true; + prevForm = NormRepairRequest::INVALID; } consecutiveCount = 0; - prevForm = NormRepairRequest::INVALID; } else if (iterating) { @@ -2832,7 +2835,7 @@ bool NormStreamObject::StreamUpdateStatus(NormBlockId blockId) { // This is a fresh rx stream, so init the read indices read_init = false; - read_index.block = blockId; + read_index.block = blockId; // for initial SYNC_STREAM sync, this will be zero (stream beginning) read_index.segment = 0; read_offset = 0; } @@ -3940,6 +3943,7 @@ void NormObjectTable::Destroy() { // TBD - should we issue PURGED/ABORTED notifications here??? // (We haven't since this is destroyed only when session is terminated) + // or when a NormSenderNode is deleted Remove(obj); obj->Release(); } diff --git a/src/common/normSession.cpp b/src/common/normSession.cpp index 8c0f723..129332a 100644 --- a/src/common/normSession.cpp +++ b/src/common/normSession.cpp @@ -32,7 +32,7 @@ NormSession::NormSession(NormSessionMgr& sessionMgr, NormNodeId localNodeId) : session_mgr(sessionMgr), notify_pending(false), tx_port(0), tx_port_reuse(false), tx_socket_actual(ProtoSocket::UDP), tx_socket(&tx_socket_actual), rx_socket(ProtoSocket::UDP), rx_cap(NULL), rx_port_reuse(false), local_node_id(localNodeId), - ttl(DEFAULT_TTL), tos(0), loopback(false), fragmentation(false), ecn_enabled(false), + ttl(DEFAULT_TTL), tos(0), loopback(false), mcast_loopback(false), fragmentation(false), ecn_enabled(false), tx_rate(DEFAULT_TRANSMIT_RATE/8.0), tx_rate_min(-1.0), tx_rate_max(-1.0), backoff_factor(DEFAULT_BACKOFF_FACTOR), is_sender(false), tx_robust_factor(DEFAULT_ROBUST_FACTOR), instance_id(0), @@ -66,8 +66,8 @@ NormSession::NormSession(NormSessionMgr& sessionMgr, NormNodeId localNodeId) user_data(NULL), next(NULL) { interface_name[0] = '\0'; - tx_socket->SetNotifier(&sessionMgr.GetSocketNotifier()); - tx_socket->SetListener(this, &NormSession::TxSocketRecvHandler); + tx_socket_actual.SetNotifier(&sessionMgr.GetSocketNotifier()); + tx_socket_actual.SetListener(this, &NormSession::TxSocketRecvHandler); tx_address.Invalidate(); rx_socket.SetNotifier(&sessionMgr.GetSocketNotifier()); @@ -112,10 +112,15 @@ NormSession::NormSession(NormSessionMgr& sessionMgr, NormNodeId localNodeId) report_timer.SetListener(this, &NormSession::OnReportTimeout); report_timer.SetInterval(10.0); report_timer.SetRepeat(-1); + + user_timer.SetListener(this, &NormSession::OnUserTimeout); + user_timer.SetInterval(0.0); + user_timer.SetRepeat(0); } NormSession::~NormSession() { + if (user_timer.IsActive()) user_timer.Deactivate(); if (NULL != preset_sender) { delete preset_sender; @@ -170,7 +175,6 @@ bool NormSession::Open() { tx_socket = &rx_socket; } - } if (!rx_socket.IsOpen() && (!tx_only || (&rx_socket == tx_socket))) { @@ -180,6 +184,7 @@ bool NormSession::Open() Close(); return false; } + rx_socket.EnableRecvDstAddr(); if (rx_port_reuse) { // Enable port/addr reuse and bind socket to destination address @@ -204,7 +209,7 @@ bool NormSession::Open() Close(); return false; } - if (rx_connect_addr.IsValid()) + if (rx_connect_addr.IsValid() && (0 != rx_connect_addr.GetPort())) { // For unicast, we use the "connect()" call to effectively // uniquely "bind" our rx_socket to the remote addr. @@ -243,7 +248,7 @@ bool NormSession::Open() Close(); return false; } - if (!tx_socket->SetLoopback(loopback)) + if (!tx_socket->SetLoopback(mcast_loopback)) { // TBD - Should this be set on the rx_socket instead??? PLOG(PL_FATAL, "NormSession::Open() tx_socket.SetLoopback() error\n"); @@ -265,7 +270,7 @@ bool NormSession::Open() } if (!tx_only) { - if (!rx_socket.JoinGroup(address, interfaceName)) + if (!rx_socket.JoinGroup(address, interfaceName, ssm_source_addr.IsValid() ? &ssm_source_addr : NULL)) { PLOG(PL_FATAL, "NormSession::Open() rx_socket.JoinGroup error\n"); Close(); @@ -371,7 +376,7 @@ void NormSession::Close() { const char* interfaceName = ('\0' != interface_name[0]) ? interface_name : NULL; - rx_socket.LeaveGroup(address, interfaceName); + rx_socket.LeaveGroup(address, interfaceName, ssm_source_addr.IsValid() ? &ssm_source_addr : NULL); } rx_socket.Close(); } @@ -406,6 +411,27 @@ bool NormSession::SetMulticastInterface(const char* interfaceName) } } // end NormSession::SetMulticastInterface() +bool NormSession::SetSSM(const char* sourceAddress) +{ + if (NULL != sourceAddress) + { + if (ssm_source_addr.ResolveFromString(sourceAddress)) + { + return true; + } + else + { + PLOG(PL_ERROR, "NormSession::SetSSM() error: invalid source address\n"); + return false; + } + } + else + { + ssm_source_addr.Invalidate(); + return true; + } +} // end NormSession::SetSSM() + bool NormSession::SetRxPortReuse(bool enableReuse, const char* rxBindAddress, // bind() to / const char* senderAddress, // connect() to / @@ -424,6 +450,7 @@ bool NormSession::SetRxPortReuse(bool enableReuse, } if (NULL != senderAddress) { + // TBD - if open, connect() to sender? if (rx_connect_addr.ResolveFromString(senderAddress)) { rx_connect_addr.SetPort(senderPort); @@ -491,18 +518,21 @@ void NormSession::SetTxOnly(bool txOnly, bool connectToSessionAddress) { tx_only = txOnly; tx_connect = connectToSessionAddress; - if (txOnly && IsOpen()) + if (IsOpen()) { - if (IsReceiver()) StopReceiver(); - if (rx_socket.IsOpen()) rx_socket.Close(); -#ifdef ECN_SUPPORT - if (NULL != rx_cap) + if (txOnly) { - rx_cap->Close(); - delete rx_cap; - rx_cap = NULL; - } + if (IsReceiver()) StopReceiver(); + if (rx_socket.IsOpen()) rx_socket.Close(); +#ifdef ECN_SUPPORT + if (NULL != rx_cap) + { + rx_cap->Close(); + delete rx_cap; + rx_cap = NULL; + } #endif // ECN_SUPPORT + } // We connect tx_only session sockets when tx port // reuse is set _and_ it is a unicast session // (This makes sure unicast NACKs get back to the right tx_socket!) @@ -530,13 +560,14 @@ double NormSession::GetTxRate() } // end NormSession::GetTxRate() +/* +// This hack can be uncommented give us a tx rate interval that is POISSON instead of PERIODIC static double PoissonRand(double mean) { return(-log(((double)rand())/((double)RAND_MAX))*mean); } - +*/ -// This hack can give us a tx rate interval that is POISSON instead of PERIODIC static inline double GetTxInterval(unsigned int msgSize, double txRate) { double interval = (double)msgSize / txRate; @@ -653,6 +684,17 @@ void NormSession::SetTxRateBounds(double rateMin, double rateMax) } // end NormSession::SetTxRateBounds() +void NormSession::SetUserTimer(double seconds) +{ + if (user_timer.IsActive()) user_timer.Deactivate(); + if (seconds >= 0.0) + { + user_timer.SetInterval(seconds); + ActivateTimer(user_timer); + } +} // end NormSession::SetUserTimer() + + bool NormSession::StartSender(UINT16 instanceId, UINT32 bufferSpace, UINT16 segmentSize, @@ -797,7 +839,7 @@ bool NormSession::StartSender(UINT16 instanceId, } else { - // Don't let txRate below MIN(one segment per grtt, one segment per seconds) + // Don't let txRate below MIN(one segment per grtt, one segment per second) txRate = ((double)segment_size) / grtt_measured; if (txRate > ((double)(segment_size))) txRate = (double)(segment_size); @@ -898,7 +940,7 @@ void NormSession::StopReceiver() // Iterate sender_tree and close/release sender nodes NormSenderNode* senderNode = static_cast(sender_tree.GetRoot()); - while (senderNode) + while (NULL != senderNode) { sender_tree.DetachNode(senderNode); senderNode->Close(); @@ -916,7 +958,7 @@ void NormSession::DeleteRemoteSender(NormSenderNode& senderNode) sender_tree.DetachNode(&senderNode); senderNode.Close(); senderNode.Release(); -} // end NormSession::DeleteSender() +} // end NormSession::DeleteRemoteSender() bool NormSession::PreallocateRemoteSender(UINT16 segmentSize, UINT16 numData, @@ -1153,7 +1195,7 @@ void NormSession::Serve() { SenderQueueFlush(); } - else if (GetTxRobustFactor() == flush_count) //xxx + else if (GetTxRobustFactor() == flush_count) { PLOG(PL_TRACE, "NormSession::Serve() node>%lu sender stream flush complete ...\n", @@ -1270,7 +1312,7 @@ void NormSession::SenderCancelWatermark() watermark_pending = false; } // end NormSession::SenderCancelWatermark() -bool NormSession::SenderAddAckingNode(NormNodeId nodeId) +NormAckingNode* NormSession::SenderAddAckingNode(NormNodeId nodeId, const ProtoAddress* srcAddress) { NormAckingNode* theNode = static_cast(acking_node_tree.FindNodeById(nodeId)); if (NULL == theNode) @@ -1281,18 +1323,19 @@ bool NormSession::SenderAddAckingNode(NormNodeId nodeId) theNode->Reset(GetTxRobustFactor()); acking_node_tree.AttachNode(theNode); acking_node_count++; - return true; } else { PLOG(PL_ERROR, "NormSession::SenderAddAckingNode() new NormAckingNode error: %s\n", GetErrorString()); + return NULL; } } else { - PLOG(PL_ERROR, "NormSession::SenderAddAckingNode() warning: node already in list!?\n"); + PLOG(PL_WARN, "NormSession::SenderAddAckingNode() warning: node already in list!?\n"); } - return true; + if (NULL != srcAddress) theNode->SetAddress(*srcAddress); + return theNode; } // end NormSession::AddAckingNode(NormNodeId nodeId) void NormSession::SenderRemoveAckingNode(NormNodeId nodeId) @@ -1967,33 +2010,45 @@ char* NormSession::SenderGetFreeSegment(NormObjectId objectId, return segment_pool.Get(); } // end NormSession::SenderGetFreeSegment() -void NormSession::TxSocketRecvHandler(ProtoSocket& /*theSocket*/, +void NormSession::TxSocketRecvHandler(ProtoSocket& theSocket, ProtoSocket::Event theEvent) { if (ProtoSocket::RECV == theEvent) { NormMsg msg; unsigned int msgLength = NormMsg::MAX_SIZE; - while (tx_socket->RecvFrom(msg.AccessBuffer(), + while (true) + { + + if (theSocket.RecvFrom(msg.AccessBuffer(), msgLength, msg.AccessAddress())) - { - if (0 == msgLength) break; // no more data to read - if (msg.InitFromBuffer(msgLength)) { - HandleReceiveMessage(msg, true); - msgLength = NormMsg::MAX_SIZE; + if (0 == msgLength) break; // no more data to read + if (msg.InitFromBuffer(msgLength)) + { + // Since it arrived on the tx_socket, we know it was unicast + HandleReceiveMessage(msg, true); + msgLength = NormMsg::MAX_SIZE; + } + else + { + PLOG(PL_ERROR, "NormSession::TxSocketRecvHandler() warning: received bad message\n"); + } } else { - PLOG(PL_ERROR, "NormSession::TxSocketRecvHandler() warning: received bad message\n"); + // Probably an ICMP "port unreachable" error + if (Address().IsUnicast()) + Notify(NormController::SEND_ERROR, NULL, NULL); + break; } } } else if (ProtoSocket::SEND == theEvent) { // This is a little cheesy, but ... - tx_socket->StopOutputNotification(); + theSocket.StopOutputNotification(); if (tx_timer.IsActive()) tx_timer.Deactivate(); if (OnTxTimeout(tx_timer)) { @@ -2014,80 +2069,110 @@ int rxMeasureGapMax = 0; #endif // RX_MEASURE_ONLY void NormSession::RxSocketRecvHandler(ProtoSocket& theSocket, - ProtoSocket::Event /*theEvent*/) + ProtoSocket::Event theEvent) { - unsigned int recvCount = 0; - NormMsg msg; - unsigned int msgLength = NormMsg::MAX_SIZE; - while (theSocket.RecvFrom(msg.AccessBuffer(), - msgLength, - msg.AccessAddress())) + if (ProtoSocket::RECV == theEvent) { - if (0 == msgLength) break; - if (msg.InitFromBuffer(msgLength)) + unsigned int recvCount = 0; + NormMsg msg; + unsigned int msgLength = NormMsg::MAX_SIZE; + while (true) { + ProtoAddress destAddr; // we get the pkt destAddr to determine unicast/multicast + if (theSocket.RecvFrom(msg.AccessBuffer(), + msgLength, + msg.AccessAddress(), + destAddr)) + { + if (0 == msgLength) break; + if (msg.InitFromBuffer(msgLength)) + { #ifdef RX_MEASURE_ONLY - // Measure rx rate / loss stats only - struct timeval currentTime; - ProtoSystemTime(currentTime); - UINT16 seq = msg.GetSequence(); - if (rxMeasureInit) - { - rxMeasureRefTime = currentTime; - rxMeasureSeqPrev = seq; - rxMeasurePktCount = rxMeasurePktTotal = 1; - rxMeasureByteTotal = msgLength; - rxMeasureInit = false; - return; - } - int seqDelta = (int)seq - (int)rxMeasureSeqPrev; - ASSERT(seqDelta > 0); - - rxMeasurePktTotal += seqDelta; // total should have received. - rxMeasurePktCount++; // total actually received - rxMeasureByteTotal += msgLength; - - if (seqDelta > rxMeasureGapMax) - rxMeasureGapMax = seqDelta; - - int deltaSec = currentTime.tv_sec - rxMeasureRefTime.tv_sec; - if (deltaSec >= 10) - { - if (currentTime.tv_usec > rxMeasureRefTime.tv_usec) - deltaSec += 1.0e-06 * (double)(currentTime.tv_usec - rxMeasureRefTime.tv_usec); - else - deltaSec -= 1.0e-06 * (double)(rxMeasureRefTime.tv_usec - currentTime.tv_usec); - double rxRate = (8.0/1000.0) * (double)rxMeasureByteTotal / (double)deltaSec; - double rxLoss = 100.0 * (1.0 - (double)rxMeasurePktCount / (double)rxMeasurePktTotal); - - rxMeasureRefTime = currentTime; - rxMeasureByteTotal = rxMeasurePktCount = rxMeasurePktTotal = rxMeasureGapMax = 0; - } - rxMeasureSeqPrev = seq; - return; + // Measure rx rate / loss stats only + struct timeval currentTime; + ProtoSystemTime(currentTime); + UINT16 seq = msg.GetSequence(); + if (rxMeasureInit) + { + rxMeasureRefTime = currentTime; + rxMeasureSeqPrev = seq; + rxMeasurePktCount = rxMeasurePktTotal = 1; + rxMeasureByteTotal = msgLength; + rxMeasureInit = false; + return; + } + int seqDelta = (int)seq - (int)rxMeasureSeqPrev; + ASSERT(seqDelta > 0); + + rxMeasurePktTotal += seqDelta; // total should have received. + rxMeasurePktCount++; // total actually received + rxMeasureByteTotal += msgLength; + + if (seqDelta > rxMeasureGapMax) + rxMeasureGapMax = seqDelta; + + int deltaSec = currentTime.tv_sec - rxMeasureRefTime.tv_sec; + if (deltaSec >= 10) + { + if (currentTime.tv_usec > rxMeasureRefTime.tv_usec) + deltaSec += 1.0e-06 * (double)(currentTime.tv_usec - rxMeasureRefTime.tv_usec); + else + deltaSec -= 1.0e-06 * (double)(rxMeasureRefTime.tv_usec - currentTime.tv_usec); + double rxRate = (8.0/1000.0) * (double)rxMeasureByteTotal / (double)deltaSec; + double rxLoss = 100.0 * (1.0 - (double)rxMeasurePktCount / (double)rxMeasurePktTotal); + + rxMeasureRefTime = currentTime; + rxMeasureByteTotal = rxMeasurePktCount = rxMeasurePktTotal = rxMeasureGapMax = 0; + } + rxMeasureSeqPrev = seq; + return; #endif // RX_MEASURE_ONLY - bool ecnStatus = false; + bool ecnStatus = false; #ifdef SIMULATE - ecnStatus = theSocket.GetEcnStatus(); - //if (ecnStatus) TRACE("NORM RECEIVED PACKET W/ ECN BIT SET!!!!!\n"); + ecnStatus = theSocket.GetEcnStatus(); + //if (ecnStatus) TRACE("NORM RECEIVED PACKET W/ ECN BIT SET!!!!!\n"); #endif // SIMULATE - HandleReceiveMessage(msg, false, ecnStatus); - msgLength = NormMsg::MAX_SIZE; - } - else - { - PLOG(PL_ERROR, "NormSession::RxSocketRecvHandler() warning: received bad message\n"); - } - // If our system gets very busy reading sockets, we should occasionally - // execute any timeouts to keep protocol operation smooth (i.e., sending feedback) - // TBD - perhaps this should be time based - if (++recvCount >= 100) - { - break; - //session_mgr.DoSystemTimeout(); - //recvCount = 0; + bool wasUnicast; + if (destAddr.IsValid()) + wasUnicast = destAddr.IsUnicast(); + else + wasUnicast = false; + HandleReceiveMessage(msg, wasUnicast, ecnStatus); + msgLength = NormMsg::MAX_SIZE; + } + else + { + PLOG(PL_ERROR, "NormSession::RxSocketRecvHandler() warning: received bad message\n"); + } + // If our system gets very busy reading sockets, we should occasionally + // execute any timeouts to keep protocol operation smooth (i.e., sending feedback) + // TBD - perhaps this should be time based + if (++recvCount >= 100) + { + break; + //session_mgr.DoSystemTimeout(); + //recvCount = 0; + } + } + else + { + // Probably an ICMP "port unreachable" error + if (Address().IsUnicast()) + Notify(NormController::SEND_ERROR, NULL, NULL); + break; + } } } + else if (ProtoSocket::SEND == theEvent) + { + // This is a little cheesy, but ... + theSocket.StopOutputNotification(); + if (tx_timer.IsActive()) tx_timer.Deactivate(); + if (OnTxTimeout(tx_timer)) + { + if (!tx_timer.IsActive()) ActivateTimer(tx_timer); + } + } // end if/else (theEvent == RECV/SEND) } // end NormSession::RxSocketRecvHandler() @@ -2176,8 +2261,24 @@ void NormSession::OnPktCapture(ProtoChannel& theChannel, continue; // not a UDP packet for our session, go read next packet // If our rx_socket is "connected", make sure source addr/port matches srcIp.SetPort(udpPkt.GetSrcPort()); - if (rx_connect_addr.IsValid() && !rx_connect_addr.IsEqual(srcIp)) - continue; // not from the remote tx_socket to which we are "connected" + // if socket is connected, validate that the packet's from the specified source addr + if (rx_connect_addr.IsValid()) + { + if (0 != rx_connect_addr.GetPort()) + { + // check host addr component only for match + if (!rx_connect_addr.HostIsEqual(srcIp)) continue; + + + } + else + { + // check for addr _and_ port match + if (!rx_connect_addr.IsEqual(srcIp)) continue; + } + } + // if we are using SSM multicast make sure it's the right source addr + if (ssm_source_addr.IsValid() && !ssm_source_addr.HostIsEqual(srcIp)) continue; // IMPORTANT NOTE: We ignore the checksum for OUTBOUND packets since these // are often computed by the Ethernet hardware these days @@ -2194,7 +2295,7 @@ void NormSession::OnPktCapture(ProtoChannel& theChannel, { msg.AccessAddress() = srcIp; - HandleReceiveMessage(msg, !dstIp.IsMulticast(), (ProtoSocket::ECN_CE == ecnStatus)); + HandleReceiveMessage(msg, dstIp.IsUnicast(), (ProtoSocket::ECN_CE == ecnStatus)); } else { @@ -2209,7 +2310,8 @@ void NormTrace(const struct timeval& currentTime, NormNodeId localId, const NormMsg& msg, bool sent, - UINT8 fecM) + UINT8 fecM, + UINT16 instId) { static const char* MSG_NAME[] = { @@ -2270,7 +2372,7 @@ void NormTrace(const struct timeval& currentTime, { const NormInfoMsg& info = (const NormInfoMsg&)msg; PLOG(PL_ALWAYS, "inst>%hu seq>%hu INFO obj>%hu ", - info.GetInstanceId(), seq, (UINT16)info.GetObjectId()); + info.GetInstanceId(), seq, (UINT16)info.GetObjectId()); break; } case NormMsg::DATA: @@ -2367,6 +2469,7 @@ void NormTrace(const struct timeval& currentTime, case NormMsg::ACK: case NormMsg::NACK: { + PLOG(PL_ALWAYS, "inst>%hu ", instId); // look for NormCCFeedback extension NormHeaderExtension ext; while (msg.GetNextExtension(ext)) @@ -2394,7 +2497,7 @@ void NormTrace(const struct timeval& currentTime, } else { - PLOG(PL_ALWAYS, "ACK(XXX) "); + PLOG(PL_ALWAYS, "ACK(ZZZ) "); } } else @@ -2425,7 +2528,42 @@ void NormSession::HandleReceiveMessage(NormMsg& msg, bool wasUnicast, bool ecnSt struct timeval currentTime; ::ProtoSystemTime(currentTime); - if (trace) NormTrace(currentTime, LocalNodeId(), msg, false, 16); // TBD don't assume m == 16 (i.e. for fec_id == 2) + if (trace) + { + // Initially assume it's a message we generated (or similarly configured sender) + UINT8 fecM = fec_m; + UINT16 instId = instance_id; + NormNodeId senderId; + switch (msg.GetType()) + { + case NormMsg::ACK: + senderId = static_cast(msg).GetSenderId(); + break; + case NormMsg::NACK: + senderId = static_cast(msg).GetSenderId(); + break; + default: + senderId = msg.GetSourceId(); + break; + } + if (IsReceiver() && (senderId != LocalNodeId())) + { + // Use our receiver state to look up sender if possible + NormSenderNode* sender = static_cast(sender_tree.FindNodeById(senderId)); + if (NULL != sender) + { + fecM = sender->GetFecFieldSize(); + instId = sender->GetInstanceId(); + } + else + { + fecM = 16; // reasonable assumption + instId = 0; + } + } + + NormTrace(currentTime, LocalNodeId(), msg, false, fecM, instId); // TBD don't assume m == 16 (i.e. for fec_id == 2) + } NormMsg::Type msgType = msg.GetType(); @@ -2454,6 +2592,8 @@ void NormSession::HandleReceiveMessage(NormMsg& msg, bool wasUnicast, bool ecnSt { if (!SenderAddAckingNode(msg.GetSourceId())) PLOG(PL_ERROR, "NormSession::HandleReceiveMessage() error: unable to add acking node!\n"); + NormAckingNode* acker = (NormAckingNode*)acking_node_tree.FindNodeById(sourceId); + Notify(NormController::ACKING_NODE_NEW, acker, NULL); } } } @@ -2512,7 +2652,8 @@ void NormSession::ReceiverHandleObjectMessage(const struct timeval& currentTim { PLOG(PL_INFO, "NormSession::ReceiverHandleObjectMessage() node>%lu sender>%lu instanceId change - resyncing.\n", LocalNodeId(), theSender->GetId()); - theSender->Close(); + theSender->Close(); + Notify(NormController::REMOTE_SENDER_RESET, theSender, NULL); if (!theSender->Open(msg.GetInstanceId())) { PLOG(PL_ERROR, "NormSession::ReceiverHandleObjectMessage() node>%lu error re-opening NormSenderNode\n"); @@ -2528,6 +2669,7 @@ void NormSession::ReceiverHandleObjectMessage(const struct timeval& currentTim theSender = preset_sender; preset_sender = NULL; theSender->SetId(msg.GetSourceId()); + theSender->SetAddress(msg.GetSource()); theSender->SetInstanceId(msg.GetInstanceId()); sender_tree.AttachNode(theSender); PLOG(PL_DEBUG, "NormSession::ReceiverHandleObjectMessage() node>%lu new remote sender:%lu ...\n", @@ -2535,6 +2677,7 @@ void NormSession::ReceiverHandleObjectMessage(const struct timeval& currentTim } else if (NULL != (theSender = new NormSenderNode(*this, msg.GetSourceId()))) { + theSender->SetAddress(msg.GetSource()); Notify(NormController::REMOTE_SENDER_NEW, theSender, NULL); if (theSender->Open(msg.GetInstanceId())) { @@ -2558,7 +2701,12 @@ void NormSession::ReceiverHandleObjectMessage(const struct timeval& currentTim } } theSender->Activate(true); - theSender->SetAddress(msg.GetSource()); + if (!theSender->GetAddress().IsEqual(msg.GetSource())) + { + // sender source address has changed + theSender->SetAddress(msg.GetSource()); + Notify(NormController::REMOTE_SENDER_ADDRESS, theSender, NULL); + } theSender->UpdateRecvRate(currentTime, msg.GetLength()); //if (ecnStatus) TRACE("UPDATING LOSS EST w/ ECN pkt\n"); theSender->UpdateLossEstimate(currentTime, msg.GetSequence(), ecnStatus); @@ -2576,13 +2724,14 @@ void NormSession::ReceiverHandleCommand(const struct timeval& currentTime, // Do common updates for senders we already know. NormNodeId sourceId = cmd.GetSourceId(); NormSenderNode* theSender = (NormSenderNode*)sender_tree.FindNodeById(sourceId); - if (theSender) + if (NULL != theSender) { if (cmd.GetInstanceId() != theSender->GetInstanceId()) { PLOG(PL_INFO, "NormSession::ReceiverHandleCommand() node>%lu sender>%lu instanceId change - resyncing.\n", LocalNodeId(), theSender->GetId()); theSender->Close(); + Notify(NormController::REMOTE_SENDER_RESET, theSender, NULL); if (!theSender->Open(cmd.GetInstanceId())) { PLOG(PL_ERROR, "NormSession::ReceiverHandleCommand() node>%lu error re-opening NormSenderNode\n"); @@ -2600,6 +2749,7 @@ void NormSession::ReceiverHandleCommand(const struct timeval& currentTime, theSender = preset_sender; preset_sender = NULL; theSender->SetId(cmd.GetSourceId()); + theSender->SetAddress(cmd.GetSource()); theSender->SetInstanceId(cmd.GetInstanceId()); sender_tree.AttachNode(theSender); PLOG(PL_DEBUG, "NormSession::ReceiverHandleObjectMessage() node>%lu new remote sender:%lu ...\n", @@ -2608,6 +2758,7 @@ void NormSession::ReceiverHandleCommand(const struct timeval& currentTime, else if ((theSender = new NormSenderNode(*this, cmd.GetSourceId()))) { Notify(NormController::REMOTE_SENDER_NEW, theSender, NULL); + theSender->SetAddress(cmd.GetSource()); if (theSender->Open(cmd.GetInstanceId())) { sender_tree.AttachNode(theSender); @@ -2634,7 +2785,12 @@ void NormSession::ReceiverHandleCommand(const struct timeval& currentTime, theSender->Activate(true); else theSender->Activate(false); - theSender->SetAddress(cmd.GetSource()); + if (!theSender->GetAddress().IsEqual(cmd.GetSource())) + { + // sender source address has changed + theSender->SetAddress(cmd.GetSource()); + Notify(NormController::REMOTE_SENDER_ADDRESS, theSender, NULL); + } theSender->UpdateRecvRate(currentTime, cmd.GetLength()); theSender->UpdateLossEstimate(currentTime, cmd.GetSequence(), ecnStatus); theSender->IncrementRecvTotal(cmd.GetLength()); // for statistics only (TBD) #ifdef NORM_DEBUG @@ -3076,14 +3232,14 @@ void NormSession::SenderHandleNackMessage(const struct timeval& currentTime, Nor if (GetDebugLevel() >= PL_DEBUG) { - PLOG(PL_ALWAYS, "node>%lu sender (tactive:%d)received NACK message with content:\n", + PLOG(PL_ALWAYS, "node>%lu sender (tactive:%d) received NACK message with content:\n", LocalNodeId(), repair_timer.IsActive()); LogRepairContent(nack.GetRepairContent(), nack.GetRepairContentLength(), fec_id, fec_m); PLOG(PL_ALWAYS, "\n"); } // (TBD) maintain average of "numErasures" for SEGMENT repair requests - // to use as input to a an automatic "auto parity" adjustor + // to use as input to a future automatic "auto parity" adjustor??? // Update GRTT estimate struct timeval grttResponse; nack.GetGrttResponse(grttResponse); @@ -3660,8 +3816,8 @@ void NormSession::ReceiverHandleAckMessage(const NormAckMsg& ack) } else { - PLOG(PL_DEBUG, "NormSession::ReceiverHandleAckMessage() node>%lu heard ACK for unknown sender.\n", - LocalNodeId()); + PLOG(PL_DEBUG, "NormSession::ReceiverHandleAckMessage() node>%lu heard ACK for unknown sender>%lu.\n", + LocalNodeId(), ack.GetSenderId()); } } // end NormSession::ReceiverHandleAckMessage() @@ -4239,16 +4395,17 @@ bool NormSession::SendMessage(NormMsg& msg) // (TBD) fill in InstanceId fields on all messages as needed // We need "fec_m" for the message for NormTrace() purposes UINT8 fecM = fec_m; // assume it's a sender message (will be overridden otherwise) + UINT16 instId = instance_id; // assume it's a sender message (will be overridden otherwise) switch (msg.GetType()) { case NormMsg::INFO: case NormMsg::DATA: - ((NormObjectMsg&)msg).SetInstanceId(instance_id); + ((NormObjectMsg&)msg).SetInstanceId(instId); msg.SetSequence(tx_sequence++); // (TBD) set for session dst msgs break; case NormMsg::CMD: { - ((NormCmdMsg&)msg).SetInstanceId(instance_id); + ((NormCmdMsg&)msg).SetInstanceId(instId); switch (((NormCmdMsg&)msg).GetFlavor()) { case NormCmdMsg::CC: @@ -4276,6 +4433,7 @@ bool NormSession::SendMessage(NormMsg& msg) (NormSenderNode*)sender_tree.FindNodeById(nack.GetSenderId()); ASSERT(NULL != theSender); fecM = theSender->GetFecFieldSize(); + instId = theSender->GetInstanceId(); struct timeval currentTime; ProtoSystemTime(currentTime); struct timeval grttResponse; @@ -4292,6 +4450,7 @@ bool NormSession::SendMessage(NormMsg& msg) (NormSenderNode*)sender_tree.FindNodeById(ack.GetSenderId()); ASSERT(NULL != theSender); fecM = theSender->GetFecFieldSize(); + instId = theSender->GetInstanceId(); struct timeval grttResponse; struct timeval currentTime; ProtoSystemTime(currentTime); @@ -4325,7 +4484,7 @@ bool NormSession::SendMessage(NormMsg& msg) { struct timeval currentTime; ProtoSystemTime(currentTime); - NormTrace(currentTime, LocalNodeId(), msg, true, fecM); + NormTrace(currentTime, LocalNodeId(), msg, true, fecM, instId); } // Update sent rate tracker even if dropped (for testing/debugging) sent_accumulator.Increment(msgSize); @@ -4340,7 +4499,7 @@ bool NormSession::SendMessage(NormMsg& msg) { struct timeval currentTime; ProtoSystemTime(currentTime); - NormTrace(currentTime, LocalNodeId(), msg, true, fecM); + NormTrace(currentTime, LocalNodeId(), msg, true, fecM, instId); } // To keep track of _actual_ sent rate sent_accumulator.Increment(msgSize); @@ -4349,7 +4508,8 @@ bool NormSession::SendMessage(NormMsg& msg) } else { - PLOG(PL_DETAIL, "NormSession::SendMessage() sendto() error: %s\n", GetErrorString()); + PLOG(PL_ERROR, "NormSession::SendMessage() sendto(%s/%hu) error: %s\n", + msg.GetDestination().GetHostString(), msg.GetDestination().GetPort(), GetErrorString()); tx_sequence--; return false; } @@ -4876,10 +5036,19 @@ bool NormSession::OnReportTimeout(ProtoTimer& /*theTimer*/) struct tm* ct = &timeStruct; #else time_t secs = (time_t)currentTime.tv_sec; - struct tm* ct = gmtime(&secs); + struct tm timeStruct; + //struct tm* ct = gmtime(&secs); +#ifdef WIN32 + gmtime_s(&timeStruct, &secs); + struct tm* ct = &timeStruct; +#else + struct tm* ct = gmtime_r(&secs, &timeStruct); +#endif + #endif // if/else _WIN32_WCE + ASSERT(NULL != ct); PLOG(PL_INFO, "REPORT time>%02d:%02d:%02d.%06lu node>%lu ***************************************\n", - ct->tm_hour, ct->tm_min, ct->tm_sec, currentTime.tv_usec, LocalNodeId()); + ct->tm_hour, ct->tm_min, ct->tm_sec, currentTime.tv_usec, LocalNodeId()); if (IsSender()) { PLOG(PL_INFO, "Local status:\n"); @@ -4925,6 +5094,14 @@ bool NormSession::OnReportTimeout(ProtoTimer& /*theTimer*/) return true; } // end NormSession::OnReportTimeout() +bool NormSession::OnUserTimeout(ProtoTimer& /*theTimer*/) +{ + Notify(NormController::USER_TIMEOUT, (NormSenderNode*)NULL, (NormObject*)NULL); + return true; +} // end NormSession::OnUserTimeout( + + + NormSessionMgr::NormSessionMgr(ProtoTimerMgr& timerMgr, ProtoSocket::Notifier& socketNotifier, ProtoChannel::Notifier* channelNotifier) diff --git a/src/common/pcap2norm.cpp b/src/common/pcap2norm.cpp index fa2268d..a774dc3 100644 --- a/src/common/pcap2norm.cpp +++ b/src/common/pcap2norm.cpp @@ -342,7 +342,8 @@ void NormTrace2(const struct timeval& currentTime, clrFlag = ((NormCCFeedbackExtension&)ext).CCFlagIsSet(NormCC::CLR); // Print ccRtt (only valid if pcap file is from sender node) double ccRtt = NormUnquantizeRtt(((NormCCFeedbackExtension&)ext).GetCCRtt()); - PLOG(PL_ALWAYS, "ccRtt:%lf ", ccRtt); + double ccLoss = NormUnquantizeLoss32(((NormCCFeedbackExtension&)ext).GetCCLoss32()); + PLOG(PL_ALWAYS, "ccRtt:%lf ccLoss:%lf ", ccRtt, ccLoss); break; } } diff --git a/src/java/jni/normEventJni.cpp b/src/java/jni/normEventJni.cpp index 75e7922..fb17dec 100644 --- a/src/java/jni/normEventJni.cpp +++ b/src/java/jni/normEventJni.cpp @@ -6,8 +6,7 @@ JNIEXPORT jobject JNICALL PKGNAME(NormEvent_getObject) NormObjectHandle objectHandle; jobject object = NULL; - objectHandle = (NormObjectHandle)env->GetLongField(obj, - fid_NormEvent_objectHandle); + objectHandle = (NormObjectHandle)env->GetLongField(obj, fid_NormEvent_objectHandle); switch (NormObjectGetType(objectHandle)) { case NORM_OBJECT_DATA: diff --git a/src/java/jni/normSessionJni.cpp b/src/java/jni/normSessionJni.cpp index 1c7322c..f3c4eef 100644 --- a/src/java/jni/normSessionJni.cpp +++ b/src/java/jni/normSessionJni.cpp @@ -95,6 +95,26 @@ JNIEXPORT void JNICALL PKGNAME(NormSession_setMulticastInterface) env->ReleaseStringUTFChars(interfaceName, str); } + +JNIEXPORT void JNICALL PKGNAME(NormSession_setSSM) + (JNIEnv *env, jobject obj, jstring sourceAddr) { + NormSessionHandle session; + const char *str; + + session = (NormSessionHandle)env->GetLongField(obj, fid_NormSession_handle); + + str = env->GetStringUTFChars(sourceAddr, NULL); + + if (!NormSetSSM(session, str)) { + env->ReleaseStringUTFChars(sourceAddr, str); + env->ThrowNew((jclass)env->NewLocalRef(jw_IOException), "Failed to set SSM source address"); + return; + } + + env->ReleaseStringUTFChars(sourceAddr, str); +} + + JNIEXPORT void JNICALL PKGNAME(NormSession_setTTL) (JNIEnv *env, jobject obj, jbyte ttl) { NormSessionHandle session; diff --git a/src/java/jni/normSessionJni.h b/src/java/jni/normSessionJni.h index e3ea161..49ff473 100644 --- a/src/java/jni/normSessionJni.h +++ b/src/java/jni/normSessionJni.h @@ -42,7 +42,7 @@ JNIEXPORT void JNICALL Java_mil_navy_nrl_norm_NormSession_setRxPortReuse /* * Class: mil_navy_nrl_norm_NormSession * Method: setEcnSupport - * Signature: (ZZ)V + * Signature: (ZZZ)V */ JNIEXPORT void JNICALL Java_mil_navy_nrl_norm_NormSession_setEcnSupport (JNIEnv *, jobject, jboolean, jboolean, jboolean); @@ -55,6 +55,14 @@ JNIEXPORT void JNICALL Java_mil_navy_nrl_norm_NormSession_setEcnSupport JNIEXPORT void JNICALL Java_mil_navy_nrl_norm_NormSession_setMulticastInterface (JNIEnv *, jobject, jstring); +/* + * Class: mil_navy_nrl_norm_NormSession + * Method: setSSM + * Signature: (Ljava/lang/String;)V + */ +JNIEXPORT void JNICALL Java_mil_navy_nrl_norm_NormSession_setSSM + (JNIEnv *, jobject, jstring); + /* * Class: mil_navy_nrl_norm_NormSession * Method: setTTL @@ -321,7 +329,7 @@ JNIEXPORT void JNICALL Java_mil_navy_nrl_norm_NormSession_cancelWatermark /* * Class: mil_navy_nrl_norm_NormSession - * Method: cancelWatermark + * Method: resetWatermark * Signature: ()V */ JNIEXPORT void JNICALL Java_mil_navy_nrl_norm_NormSession_resetWatermark diff --git a/src/java/src/mil/navy/nrl/norm/NormEvent.java b/src/java/src/mil/navy/nrl/norm/NormEvent.java index f0a069c..1bcf9ed 100644 --- a/src/java/src/mil/navy/nrl/norm/NormEvent.java +++ b/src/java/src/mil/navy/nrl/norm/NormEvent.java @@ -31,7 +31,7 @@ public class NormEvent { } /** - * @return Returns the node. + * @return Returns the session. */ public NormSession getSession() { if (sessionHandle == 0) { @@ -51,6 +51,9 @@ public class NormEvent { return new NormNode(nodeHandle); } + /** + * @return Returns the object. + */ public native NormObject getObject(); /** diff --git a/src/java/src/mil/navy/nrl/norm/NormObject.java b/src/java/src/mil/navy/nrl/norm/NormObject.java index 154f842..72113f9 100644 --- a/src/java/src/mil/navy/nrl/norm/NormObject.java +++ b/src/java/src/mil/navy/nrl/norm/NormObject.java @@ -11,7 +11,7 @@ import mil.navy.nrl.norm.enums.NormObjectType; * @author Jason Rush */ public class NormObject { - private long handle; // The pointer to the native NormInstanceHandle + private long handle; // The pointer to the native NormObjectHandle NormObject(long handle) { this.handle = handle; diff --git a/src/java/src/mil/navy/nrl/norm/NormSession.java b/src/java/src/mil/navy/nrl/norm/NormSession.java index d6fdf11..dd286f4 100644 --- a/src/java/src/mil/navy/nrl/norm/NormSession.java +++ b/src/java/src/mil/navy/nrl/norm/NormSession.java @@ -19,7 +19,7 @@ import mil.navy.nrl.norm.enums.NormSyncPolicy; public class NormSession { private static Map normSessions = new HashMap(); - private long handle; // The pointer to the native NormInstanceHandle + private long handle; // The pointer to the native NormSessionHandle /** * Package protected constructor is invoked by NormInstance @@ -38,7 +38,6 @@ public class NormSession { public void destroySession() { normSessions.remove(handle); - destroySessionNative(); } @@ -63,7 +62,10 @@ public class NormSession { public native void setMulticastInterface(String interfaceName) throws IOException; - + + public native void setSSM(String sourceAddr) + throws IOException; + public native void setTTL(byte ttl) throws IOException; public native void setTOS(byte tos) throws IOException; diff --git a/src/java/src/mil/navy/nrl/norm/enums/NormEventType.java b/src/java/src/mil/navy/nrl/norm/enums/NormEventType.java index 5a023fa..7d5d1c2 100644 --- a/src/java/src/mil/navy/nrl/norm/enums/NormEventType.java +++ b/src/java/src/mil/navy/nrl/norm/enums/NormEventType.java @@ -19,6 +19,8 @@ public enum NormEventType { NORM_TX_RATE_CHANGED, NORM_LOCAL_SENDER_CLOSED, NORM_REMOTE_SENDER_NEW, + NORM_REMOTE_SENDER_RESET, + NORM_REMOTE_SENDER_ADDRESS, NORM_REMOTE_SENDER_ACTIVE, NORM_REMOTE_SENDER_INACTIVE, NORM_REMOTE_SENDER_PURGED, diff --git a/src/java/src/mil/navy/nrl/norm/enums/NormSyncPolicy.java b/src/java/src/mil/navy/nrl/norm/enums/NormSyncPolicy.java index 20d6c46..5237456 100644 --- a/src/java/src/mil/navy/nrl/norm/enums/NormSyncPolicy.java +++ b/src/java/src/mil/navy/nrl/norm/enums/NormSyncPolicy.java @@ -1,7 +1,4 @@ -/* - * Copyright (c) 2010 by General Dynamics Advanced Information Systems - * Classification: UNCLASSIFIED - */ + package mil.navy.nrl.norm.enums; /** @@ -11,6 +8,7 @@ package mil.navy.nrl.norm.enums; * * @author Jason Rush */ + public enum NormSyncPolicy { NORM_SYNC_CURRENT, NORM_SYNC_STREAM, diff --git a/src/java/src/mil/navy/nrl/norm/io/INormEventListener.java b/src/java/src/mil/navy/nrl/norm/io/INormEventListener.java index d98e3c0..11984d4 100644 --- a/src/java/src/mil/navy/nrl/norm/io/INormEventListener.java +++ b/src/java/src/mil/navy/nrl/norm/io/INormEventListener.java @@ -1,7 +1,4 @@ -/* - * Copyright (c) 2010 by General Dynamics Advanced Information Systems - * Classification: UNCLASSIFIED - */ + package mil.navy.nrl.norm.io; import mil.navy.nrl.norm.NormEvent; diff --git a/src/java/src/mil/navy/nrl/norm/io/NormInputStream.java b/src/java/src/mil/navy/nrl/norm/io/NormInputStream.java index 526ad8b..df33c35 100644 --- a/src/java/src/mil/navy/nrl/norm/io/NormInputStream.java +++ b/src/java/src/mil/navy/nrl/norm/io/NormInputStream.java @@ -1,7 +1,3 @@ -/* - * Copyright (c) 2010 by General Dynamics Advanced Information Systems - * Classification: UNCLASSIFIED - */ package mil.navy.nrl.norm.io; import java.io.IOException; @@ -33,6 +29,7 @@ public class NormInputStream extends InputStream { private Object closeLock; private boolean bufferIsEmpty; + private boolean receivedEof; public NormInputStream(String address, int port) throws IOException { // Create the NORM instance @@ -50,6 +47,7 @@ public class NormInputStream extends InputStream { closeLock = new Object(); bufferIsEmpty = true; + receivedEof = false; } public synchronized void openDebugLog(String filename) throws IOException { @@ -59,11 +57,11 @@ public class NormInputStream extends InputStream { public synchronized void closeDebugLog() { normInstance.closeDebugLog(); } - + public synchronized void setDebugLevel(int level) { normInstance.setDebugLevel(level); } - + public synchronized void setMessageTrace(boolean messageTrace) { normSession.setMessageTrace(messageTrace); } @@ -198,12 +196,12 @@ public class NormInputStream extends InputStream { } do { - while (normInstance.hasNextEvent(0, 0)) { + while (bufferIsEmpty || normInstance.hasNextEvent(0, 0)) { processEvent(); - } - while (bufferIsEmpty) { - processEvent(); + if (receivedEof) { + return -1; + } } if (normStream == null) { @@ -254,6 +252,9 @@ public class NormInputStream extends InputStream { case NORM_RX_OBJECT_ABORTED: case NORM_RX_OBJECT_COMPLETED: normStream = null; + + // Signal that the stream has ended + receivedEof = true; break; default: diff --git a/src/java/src/mil/navy/nrl/norm/io/NormOutputStream.java b/src/java/src/mil/navy/nrl/norm/io/NormOutputStream.java index c23c737..c6d2fdd 100644 --- a/src/java/src/mil/navy/nrl/norm/io/NormOutputStream.java +++ b/src/java/src/mil/navy/nrl/norm/io/NormOutputStream.java @@ -1,7 +1,4 @@ -/* - * Copyright (c) 2010 by General Dynamics Advanced Information Systems - * Classification: UNCLASSIFIED - */ + package mil.navy.nrl.norm.io; import java.io.IOException; diff --git a/src/java/src/mil/navy/nrl/norm/io/StreamBreakException.java b/src/java/src/mil/navy/nrl/norm/io/StreamBreakException.java index 51e1122..06f5a65 100644 --- a/src/java/src/mil/navy/nrl/norm/io/StreamBreakException.java +++ b/src/java/src/mil/navy/nrl/norm/io/StreamBreakException.java @@ -1,7 +1,4 @@ -/* - * Copyright (c) 2010 by General Dynamics Advanced Information Systems - * Classification: UNCLASSIFIED - */ + package mil.navy.nrl.norm.io; import java.io.IOException; diff --git a/src/pynorm/constants.py b/src/pynorm/constants.py index 4f24bca..c2ad5d0 100644 --- a/src/pynorm/constants.py +++ b/src/pynorm/constants.py @@ -58,18 +58,20 @@ NORM_TX_OBJECT_PURGED = 7 NORM_TX_RATE_CHANGED = 8 NORM_LOCAL_SENDER_CLOSED = 9 NORM_REMOTE_SENDER_NEW = 10 -NORM_REMOTE_SENDER_ACTIVE = 11 -NORM_REMOTE_SENDER_INACTIVE = 12 -NORM_REMOTE_SENDER_PURGED = 13 -NORM_RX_CMD_NEW = 14 -NORM_RX_OBJECT_NEW = 15 -NORM_RX_OBJECT_INFO = 16 -NORM_RX_OBJECT_UPDATED = 17 -NORM_RX_OBJECT_COMPLETED = 18 -NORM_RX_OBJECT_ABORTED = 19 -NORM_GRTT_UPDATED = 20 -NORM_CC_ACTIVE = 21 -NORM_CC_INACTIVE = 22 +NORM_REMOTE_SENDER_RESET = 11 +NORM_REMOTE_SENDER_ADDRESS = 12 +NORM_REMOTE_SENDER_ACTIVE = 13 +NORM_REMOTE_SENDER_INACTIVE = 14 +NORM_REMOTE_SENDER_PURGED = 15 +NORM_RX_CMD_NEW = 16 +NORM_RX_OBJECT_NEW = 17 +NORM_RX_OBJECT_INFO = 18 +NORM_RX_OBJECT_UPDATED = 19 +NORM_RX_OBJECT_COMPLETED = 20 +NORM_RX_OBJECT_ABORTED = 21 +NORM_GRTT_UPDATED = 22 +NORM_CC_ACTIVE = 23 +NORM_CC_INACTIVE = 24 diff --git a/src/pynorm/core.py b/src/pynorm/core.py index 1d0b74c..d18a5a2 100644 --- a/src/pynorm/core.py +++ b/src/pynorm/core.py @@ -154,10 +154,13 @@ def get_libnorm(): ctypes.c_bool, ctypes.c_bool] libnorm.NormSetMulticastInterface.restype = ctypes.c_bool - libnorm.NormSetMulticastInterface.argtypes = [ctypes.c_void_p, - ctypes.c_char_p] + libnorm.NormSetMulticastInterface.argtypes = [ctypes.c_void_p, ctypes.c_char_p] libnorm.NormSetMulticastInterface.errcheck = errcheck_bool - + + libnorm.NormSetSSM.restype = ctypes.c_bool + libnorm.NormSetSSM.argtypes = [ctypes.c_void_p, ctypes.c_char_p] + libnorm.NormSetSSM.errcheck = errcheck_bool + libnorm.NormSetTTL.restype = ctypes.c_bool libnorm.NormSetTTL.argtypes = [ctypes.c_void_p, ctypes.c_uint8] libnorm.NormSetTTL.errcheck = errcheck_bool diff --git a/src/pynorm/event.py b/src/pynorm/event.py index 8439932..a9a17e5 100644 --- a/src/pynorm/event.py +++ b/src/pynorm/event.py @@ -63,6 +63,10 @@ class Event(object): return "NORM_LOCAL_SENDER_CLOSED" elif self.type == c.NORM_REMOTE_SENDER_NEW: return "NORM_REMOTE_SENDER_NEW" + elif self.type == c.NORM_REMOTE_SENDER_RESET: + return "NORM_REMOTE_SENDER_RESET" + elif self.type == c.NORM_REMOTE_SENDER_ADDRESS: + return "NORM_REMOTE_SENDER_ADDRESS" elif self.type == c.NORM_REMOTE_SENDER_ACTIVE: return "NORM_REMOTE_SENDER_ACTIVE" elif self.type == c.NORM_REMOTE_SENDER_INACTIVE: diff --git a/src/pynorm/session.py b/src/pynorm/session.py index 7655f29..9c6924f 100644 --- a/src/pynorm/session.py +++ b/src/pynorm/session.py @@ -49,7 +49,10 @@ class Session(object): def setMulticastInterface(self, iface): libnorm.NormSetMulticastInterface(self, iface) - + + def setSSM(self, srcAddr): + libnorm.NormSetSSM(self, srcAddr) + def setTTL(self, ttl): libnorm.NormSetTTL(self, ttl) diff --git a/src/sim/opnet/12.0/norm_protolib.pr.cpp b/src/sim/opnet/12.0/norm_protolib.pr.cpp index 1656eeb..246bd30 100644 --- a/src/sim/opnet/12.0/norm_protolib.pr.cpp +++ b/src/sim/opnet/12.0/norm_protolib.pr.cpp @@ -1,8 +1,6 @@ /* Process model C++ form file: norm_protolib.pr.cpp */ /* Portions of this file copyright 1992-2006 by OPNET Technologies, Inc. */ - - /* This variable carries the header into the object file */ const char norm_protolib_pr_cpp [] = "MIL_3_Tfile_Hdr_ 120A 30A modeler 7 464DEF85 464DEF85 1 wn12jh Jim@Hauser 0 0 none none 0 0 none 0 0 0 0 0 0 0 0 10de 3 "; #include diff --git a/waf b/waf index 4e68fed..f6e9616 100755 Binary files a/waf and b/waf differ