xview

package: libxview-devel

title: xview(7)

summary: xview toolkit information

text:
# xview(7)

## NAME
xview - xview toolkit information

## SYNOPSIS
There is no xview command per se, but this manual page will briefly describe XView features and functions.

## AVAILABILITY
XView is available with the OpenWindows distribution.

## DESCRIPTION
XView (X Window-System-based Visual/Integrated Environment for Workstations) is an Open Look user-interface toolkit which supports development of interactive, graphics-based applications running under the X Window System. For detailed information see the XView Programming Manual and the XView Reference Manual.

## USAGE

### Compiling XView Programs
XView programs are compiled with the following command line:

cc sourcefile.c -o outputfile -lxview -lolgx -lX11

### Generic XView Functions
xv_init()

Establishes the connection to the server, initializes the Notifier and the Defaults/Resource-Manager database, loads the Server Resource-Manager database, reads any passed attributes, and installs a default X11 Errorhandler.

```
Xv_Server
xv_init(attrs)

    <attribute-value list> attrs;
```

Note: attrs is a NULL terminated attribute-value list.

xv_create()

Creates an object.

```
Xv_object
xv_create(owner, package, attrs)

    Xv_object      owner;

    Xv_pkg         package;

    <attribute-value list> attrs;
```

xv_destroy()

Destroys an object.

```
int
xv_destroy(object)

    Xv_opaque object;
```

xv_find()

Finds an object that meets certain criteria; or if the object doesn't exist, creates it (default behavior which can be defeated using XV_AUTO_CREATE, FALSE).

```
Xv_opaque
xv_find(owner, package, attrs)

    Xv_object      owner;

    Xv_pkg         package;

    <attribute-value list> attrs;
```

xv_get()

Gets the value of a single attribute.

```
Xv_opaque
xv_get(object, attrs)

    Xv_object     object;

    <attribute-value list> attrs;
```

xv_set()

Sets the value of one or more attributes.

```
Xv_opaque
xv_set(object, attrs)

    Xv_object     object;

    <attribute-value list> attrs;
```

### Internationalized Support
XView now has support for internationalization. This includes locale setting, localized text handling, and dynamic object layout. See the XView Programming Manual for details.

### Command Line Resource Arguments
XView-based applications display characteristics can be controlled by supplying command line arguments to the applications at start-up. The usage is as follows:

% program -argument1 value1 -argument2 value2...

In the tables below, Argument(s) shows the short argument followed by the long argument—either can be used. Type describes the type of value the arguments can receive. Resource describes the X resource name modified by the arguments. Default is the default value. Description describes what the arguments do. Example shows an example of a command using the argument.

Argument(s):

-Wx, or -scale

Type:

string ("small", "medium", "large", "extra_large")

Resource:

Window.Scale

Default:

medium

Description:

Sets the initial scale of the application (larger or smaller). small is 10 pixels, medium is 12 pixels, large is 14 pixels and extra_Large is 19 pixels. The font.name resource will override the scale.

Example:

cmdtool -scale extra_large

Argument(s):

-Wt, -fn, or -font

Type:

string

Resource:

Font.Name

Default:

lucidasans-12

Description:

Sets the name of the font used for the application. Does not set the font for frame header and frame menu header. These are controlled by the window manager. To find out what fonts are available, use the xlsfonts(1) command. If the font you specify cannot be found, you will see an error message such as:

```
XView warning: Cannot load font 'galant-24' (Font package)
```

XView warning: Attempting to load font '-b&h-lucida-medium-r-normal-sans-*-120-*-*-*-*-*-*' instead (Font package)

Example:

cmdtool -fn fixed

Argument(s):

-Ws, or -size

Type:

integer integer

Resource:

Window.Width and Window.Height

Default:

depends on application

Description:

Sets the width and height of the application's base frame. The values are in pixels.

Example:

cmdtool -Ws 400 500

Argument(s):

-Ww, or -width

Type:

int (number of columns)

Resource:

window.columns

Default:

None

Description:

Specifies the width, in columns, of the application.

Example:

cmdtool -width 40

(starts a command tool 40 columns wide)

Argument(s):

-Wh, or -height

Type:

int (number of columns)

Resource:

window.rows

Default:

None

Description:

Specifies the height, in rows, of the application.

Example:

cmdtool -height 40

(starts a command tool 40 rows high)

Argument(s):

-Wp, or -position

Type:

integer integer

Resource:

Window.X and Window.Y

Default:

depends on window manager

Description:

Sets the initial position of the application's base frame in pixels. The upper left corner of the screen is at position (0,0), with the x-axis increasing to the left, and the y-axis increasing downward. These values will also be generated by the "Save Workspace" option on the root menu into the $HOME/.openwin-init file when using the Open Look Window Manager.

Example:

cmdtool -Wp 100 200

Argument(s):

-WG, or -geometry

Type:

string of the format <width>x<height>{+-}<xoffset>{+-}<yoffset>

Resource:

Window.Geometry

Default:

depends on application and window manager

Description:

This sets both the size and the placement of the application's base frame. This option has priority over the -size and -position arguments. The size and placement parts of the value are optional. You can set just the size, just the position, or both. The size values are measured in pixels, and the position values use the same semantics as -position. However, if you use the '-' in front of an X value, it will be taken as relative to the right hand side of the screen, instead of the left. Likewise, if you use the '-' with the Y value, it will be taken relative to the bottom of the screen instead of the top.

Examples:

```
cmdtool -geometry 500x600
```

(will make the base frame 500x600 pixels, with the position set by the window manager)

```
cmdtool -WG +10+20
```

(will make the base frame of default size with the left hand side of the frame 10 pixels from the left hand side of the screen, and the top of the frame 20 pixels from the top of the screen)

```
cmdtool -WG -10+20
```

(will make the base frame of default size with the right hand side of the frame 10 pixels from the right hand side of the screen, and the top of the frame 20 pixels from the top of the screen)

```
cmdtool -geometry 400x300-0-0
```

(will make the base frame 400x300 pixels with the right hand side of the frame flush against the right hand side of the screen, and the bottom of the frame flush with the bottom of the screen)

Argument(s):

-WP, -icon_position

Type:

integer integer

Resource:

Icon.X Icon.Y

Default:

depends on window manager

Description:

Sets the position of the application's icon in pixels. Uses the same semantics as -position for base frames.

Example:

cmdtool -WP 400 20

Argument(s):

-Wl, -label, or -title

Type:

string

Resource:

Window.Header

Default:

N/A

Description:

Sets a default label for the base frame's header. However, the application can overwrite this setting and display its own header.

Example:

cmdtool -Wl "Header Text"

Argument(s):

-Wi, and +Wi

Type:

boolean

Resource:

Window.Iconic

Default:

+Wi

Description:

Controls how an application will come up, open or closed (iconified).

Examples:

cmdtool +Wi (will make the cmdtool come up open)

cmdtool -Wi (will make the cmdtool come up closed)

Argument(s):

-depth

Type:

integer

Resource:

Window.Depth

Default:

Depth of server's default visual

Description:

Specifies the depth of base frame. If this depth is not supported by the server, the default depth will be used instead. If this is specified in conjunction with -visual, then the exact visual will be used.

Example:

cmdtool -depth 4

Argument(s):

-visual

Type:

string (one of the values: StaticGray, GrayScale, StaticColor, PseudoColor, TrueColor, or DirectColor).

Resource:

Window.Visual

Default:

Server's default visual

Description:

Specifies the visual class of the base frame. If this visual class is not supported by the server, the default visual class will be used instead. If this is specified in conjunction with -depth, then the exact visual will be used.

Example:

cmdtool -visual StaticGray

Argument(s):

-Wf, or -foreground_color

Type:

integer integer integer

Resource:

Window.Color.Foreground

Default:

0 0 0

Description

See Description in -Wb below.

Argument(s):

-Wb, or -background

Type:

integer integer integer

Resource:

Window.Color.Background

Default:

255 255 255

Description:

These options allow the user to specify the foreground color (e.g., the color of the text in a textsw), or the background color (e.g., the color that the text is painted on) of an application. The three values should be integers between 0 and 255. They specify the amount of red, green and blue that is in the color. See -fg and -bg below for information on similar functions.

Example:

cmdtool -Wf 0 0 255 -Wb 100 100 100

(would come up with a blue foreground, with a gray background)

Argument(s):

-fg, or -foreground

Type:

string (color name, or hexadecimal color specification)

Resource:

Window.Color.Foreground

Default:

black

Description:

See Description in -bg below.

Argument(s):

-bg, or -background

Type:

string (color name, or hexadecimal color specification)

Resource:

Window.Color.Background

Default:

white

Description:

These options are similar to the -Wf and -Wb options, except that they take a color argument in the form of a predefined color name (lavender, grey, goldenrod, etc.) from $OPENWINHOME/lib/rbg.txt, or a hexadecimal representation. The hexadecimal representation is of the form pound sign (#) followed by the hexadecimal representation of the red, green and blue aspects of the color.

Examples:

cmdtool -fg blue -bg gray

(comes up with a blue foreground, with a gray background)

cmdtool -fg #d800ff -bg white

(comes up with a purple foreground, with a white background)

Argument(s):

-WI, or -icon_image

Type:

string

Resource:

Icon.Pixmap

Default:

depends on application

Description:

Sets the default filename for the icon's image. However, the application can overwrite this setting and display its own icon image. The file must be in XView icon format. The program iconedit(1) will allow one to create an image in the icon format. Several icons have been provided in the directory $OPENWINHOME/include/images. By convention, icon format files end with the suffix .icon.

Example:

cmdtool -WI /usr/include/images/stop.icon

Argument(s):

-WL, or -icon_label

Type:

string

Resource:

Icon.Footer

Default:

depends on application

Description:

Sets a default label for the base frame's icon. However, the application can overwrite this setting and display its own icon label.

Example:

cmdtool -WL "Icon Label"

Argument(s):

-WT, or -icon_font

Type:

string

Resource:

Icon.Font.Name

Default:

depends

Description:

Sets the name of the font used for the application's icon.

Example:

cmdtool -WT '*century schoolbook*'

Argument(s):

-Wd, or -default

Type:

string string

Resource:

given by the first string

Default:

none

Description:

This option allows the user to set resources that don't have command line equivalents. The format is -default resource-name value . The XView resources without specific command line arguments are discussed in the following section.

Example:

cmdtool -default OpenWindows.ScrollbarPlacement left

Argument(s):

-xrm

Type:

string

Resource:

given in the string

Default:

none

Description:

This option allows the user to set resources that don't have command line equivalents. This is similar to the -default option, but it takes only one argument, a string in the form of resource-name:value.

Example:

cmdtool -xrm OpenWindows.ScrollbarPlacement:right

Argument(s):

-WH, or -help

Type:

none

Resource:

none

Default:

none

Description:

Prints a description of the valid xview command line arguments for the application.

Argument(s):

-sync or -synchronous, and +sync or +synchronous

Type:

boolean

Resource:

Window.Synchronous

Default:

+synchronous

Description:

These options allow you to make the connection that the application has with the X11 server either synchronous (-sync) or asynchronous (+sync).

Argument(s):

-Wr, or -display

Type:

string (host:display{.screen})

Resource:

Server.Name

Default:

taken from the DISPLAY environment variable

Description:

Sets the name of the X11 server on which to connect. host is the name or address of the machine on whose server you have permission to display. display is a number corresponding to the server on which to display for that machine, and screen corresponds to which screen for the server. See reference manual page on xhost(1) for more details on adding to permissions list.

Examples:

cmdtool -display foobar:0

(will bring up a cmdtool on the default screen of the display #0 of host foobar)

cmdtool -display foobar:0.1

(will bring up a cmdtool on screen #1 of display #0 of host foobar)

Argument(s):

-Wdxio, or -disable_xio_error_handler

Type:

boolean

Resource:

none

Default:

enable xio handler—this option disables it

Description:

This option is useful for debugging an application. Whenever there is a fatal XIO error, the server will print an error message before exiting. XView installs a error handler to keep those messages from appearing. If you would like to see these messages, use this option.

Argument(s)

-rv (or -reverse), and +rv (or +reverse)

Type:

boolean

Resource:

Window.ReverseVideo

Default:

False

Description:

These options control whether the foreground and background colors of the application will be reversed. If True, the foreground and background colors will be swapped. The -rv flag will set this to True, while the +rv will set it to False. This is really only useful on monochrome displays.

Argument(s):

-name

Type:

string

Resource:

None

Default:

argv[0]

Description:

Specifies the instance name of the application. This name is used to construct the resource name used to perform lookups in the X11 Resource Manager to look for the values of customizable attributes.

### Internationalized Command Line Resource Arguments
The following command line arguments are relevant to internationalization. Locale refers to the language and cultural conventions used in a program. Locale setting is the method by which the language and cultural environment of a system is set. Locale setting affects the display and manipulation of language-dependent features.

The internationalization features that XView now supports include locale setting. One of the ways locale can be set is with command line options. See the XView Programming Manual for details on other methods.

Argument(s):

-lc_basiclocale

Type:

string

Resource:

basicLocale

Default:

"C"

Description:

Specifies the basic locale category, which sets the country of the user interface.

Argument(s):

-lc_displaylang

Type:

string

Resource:

displayLang

Default:

"C"

Description:

Specifies the display language locale category, sets the language in which labels, messages, menu items, and help text are displayed.

Argument(s):

-lc_inputlang

Type:

string

Resource:

inputLang

Default:

"C"

Description:

Specifies the input language locale category, sets the language used for keyboard input.

Argument(s):

-lc_numeric

Type:

string

Resource:

numeric

Default:

"C"

Description:

Specifies the numeric locale category, which defines the language used to format numeric quantities.

Argument(s):

-lc_timeformat

Type:

string

Resource:

timeFormat

Default:

"C"

Description:

Specifies the time format locale category, which defines the language used to format time and date.

### Command Line Options/X Resources for Debugging
The following switches/resources can be used during development to avoid the locking up of screens or other effects of X grabs that are done by XView.

It should be noted that these options/resources should only be used by developers and are not for normal usage. The X grabs are done for a specific reason, and are not meant to be customizable. Without the X grabs, certain features in XView (those that depend on X grabs) might not function properly.

Argument(s):

-Wfsdb, or -fullscreendebug

Type:

boolean

Resource:

Fullscreen.Debug

Default:

FALSE

Description:

Enables/disables fullscreen debugging mode during which X grabs (XGrabServer(), XGrabKeyboard(), XGrabPointer()) are not done. When using the fullscreen pkg, the X11 server will be grabbed which prevents other windows on the server from responding until the grab has been released by the one window which initiated the grab. Refer to Appendix F in the XView Manual: Converting SunView Applications for further details.

Argument(s):

-Wfsdbs, or -fullscreendebugserver

Type:

boolean

Resource:

Fullscreen.Debugserver

Default:

FALSE

Description:

Enables/disables server grabbing (XGrabServer()) that is done via the fullscreen pkg. Refer to the Appendix F in the XView Manual: Converting SunView Applications for further details.

Argument(s):

-Wfsdbk, or -fullscreendebugkbd

Type:

boolean

Resource:

Fullscreen.Debugkbd

Default:

FALSE

Description:

Enables/disables keyboard grabbing (XGrabKeyboard()) that is done via the fullscreen pkg. Refer to the Appendix F in the XView Manual: Converting SunView Applications for further details.

Argument(s):

-Wfsdbp, or -fullscreendebugptr

Type:

boolean

Resource:

Fullscreen.Debugptr

Default:

FALSE

Description:

Enables/disables pointer grabbing (XGrabPointer()) that is done via the fullscreen pkg. Refer to the Appendix F in the XView Manual: Converting SunView Applications for further details.

Argument(s):

-Wdpgs, or -disable_pass_grab_select

Type:

boolean

Resource:

Window.PassiveGrab.Select

Default:

TRUE

Description:

Disables the passive grab that is done on the SELECT button. XView does a passive grab on the SELECT button to avoid input focus race conditions. When this passive grab is disabled, input focus race conditions may be seen.

Example:

% cmdtool -disable_pass_grab_select

This executes a cmdtool that does not perform any passive grabs on the SELECT button. To do the same thing using X resources, add the following entry to the X resource database:

Window.PassiveGrab.Select:False

### .Xdefaults File
The .Xdefaults file is used to store and retrieve resource settings. We recommend, however, that you use the command line arguments described above in order to change display characteristics. Changing the resources in the .Xdefaults file will modify the behaviour of the user's session. Novice users should not casually hand modify these settings. Before attempting edits to this file please read the appropriate sections of the Xlib Programming Manual on the file format and the specific properties you intend to change.

Note that resources documented below do not have command line arguments. It is still possible, however, to change them without altering the .Xdefaults file. Refer to the command line arguments -xrm and -defaults for instructions on how to to this. Additional resources that have command line arguments are documented in the previous section. For mouseless resources refer to the XView Programming Manual.

The resources are documented in the following format:

Resource:

Resource Name ( If the resource can be modified by the OpenWindows Property Sheet, the word Props will be present.)

Values:

Possible Values, and/or Format of Values to be Assigned to Resource (Default Value)

Description

Description of Resource.

Resource:

window.synchronous, +sync -sync

Values:

True, False (False)

Description

Useful when debugging or tracking down a problem since the error codes emitted from Xlib will correspond to the immediate request made. Running in a synchronous mode will cause the application to run significantly slower.

Resource:

mouse.modifier.button2

Values:

Shift, Ctrl, any valid modifier keysym (Shift)

Description

When using a mouse with less than three buttons, this resource gets an equivalent mapping for the second button which is the ADJUST button on a three button mouse. For more information on keysyms, see the xmodmap(1) reference manual page, Xlib documentation, and the include file $OPENWINHOME/include/X11/Xkeymap.h.

Resource:

mouse.modifier.button3

Values:

Shift, Ctrl, any valid modifier keysym (Ctrl)

Description

When using a mouse with less than three buttons, this resource gets an equivalent mapping for the third button which is the MENU button on a three button mouse. For more information on keysyms, see the xmodmap reference manual page, Xlib documentation, and the include file $OPENWINHOME/include/X11/Xkeymap.h.

Resource:

OpenWindows.beep (Props)

Values:

never, notices, always (always)

Description

When the value is notices, the audible bell will ring only when a notice pops up. When the value is never, the audible bell will never ring. When the value is always, the audible bell will always ring when the bell function is called by a program.

Resource:

alarm.visible

Values:

True, False (True)

Description

When ringing the bell in an XView program, flash the window as well to alert the user.

OpenWindows.windowColor (Props)

Values:

any valid X11 color specification (#cccccc—80% grey)

Description

Specify the base color for control areas for 3-D look. Takes hexadecimal representation. Three other colors used for shading and highlighting are calculated based upon the value of the specified control color. The actual calculated values are done by the OLGX library to provide a consistent color calculation between XView and OLWM. The desktop properties program allows a full range of customization and previews what the chosen 3-D look will look like. Does not apply to monochrome displays.

Resource:

OpenWindows.workspaceColor (Props)

Values:

any valid X11 color specification (#cccccc—80% grey)

Description

Specifies the color for the root window and the background color for icons that blend into the desktop.

Resource:

xview.icccmcompliant

Values:

True, False (True)

Description

When False, tells XView to set window manager hints in a way that was used before the ICCCM was adopted. Useful for window managers that were released before X11R4. Not needed with the Open Look Window Manager provided with Open Windows.

Resource:

OpenWindows.3DLook.Color

Values:

True, False (True on all but monochrome screens)

Description

When False, do not use the 3-D look on a color or greyscale screen.

Resource:

OpenWindows.dragRightDistance (Props)

Values:

N (100)

Description

Used by menus to determine when a pullright submenu would display when dragging over the menu item near a submenu. N is an integer greater than 0. A reasonable value might start at 20 and go to 200 or so. May need to try different values to see what feels best to each person.

Resource:

Selection.Timeout

Values:

N (3)

Description:

Selection timeout value. N indicates the number of seconds that a requestor or a selection owner waits for a response.

Resource:

OpenWindows.GotoMenu.RecentCount

Values:

integer between 0 and 15 (8)

Description:

Specifies the number of recently visited directories shown in the Go To Menu of a File Chooser.

Resource:

OpenWindows.GotoMenu.UserDirs

Values:

string-list (NULL)

Description:

new-line (0 separated list of full-path names to directories that is added to the top of the Go To Menu of a File Chooser.

Resource:

OpenWindows.KeyboardCommand.*

Description:

These resources determine mouseless semantic action and its corresponding key binding. Refer to the XView Reference Manual for a complete listing and explanation of the OpenWindows.KeyboardCommand.* resources. Refer to the XView Programming Manual for information on the mouseless model.

Resource:

OpenWindows.KeyboardCommands

Values:

SunView1, Basic, or Full

Description:

Controls the level of mouseless operation. All of the OpenWindows.KeyboardCommand resource mappings may be modified by users, or by specifying one the the three values for OpenWindows.KeyboardCommands. For detailed information see the XView Programming Manual

Resource:

OpenWindows.MenuAccelerators

Values:

True or False (True)

Description:

Specifies whether or not to activate all keyboard menu acceleration defined by applications. Menu accelerators are keystrokes that can be used to invoke menu commands directly. They can be seen on the right side of frequently used menu items as a set of keyboard qualifiers (with a graphical diamond mark representing the meta key) and an accelerator key.

Resource:

OpenWindows.MouseChordMenu

Values:

True, False (False)

Description:

Turns on the mouse chording mechanism. Mouse chording was implemented to allow XView to work with two-button mice. Pressing the SELECT and the ADJUST buttons at the same time will act as MENU button.

Resource:

OpenWindows.MouseChordTimeout

Values:

N (100)

Description:

Mouse chording time-out value. N is in micro-seconds.

Resource:

OpenWindows.SelectDisplaysMenu (Props)

Values:

True, False (False)

Description

When True, the SELECT button (usually left mouse) will display the menu as well as the MENU button (usually right mouse).

Resource:

OpenWindows.popupJumpCursor (Props)

Values:

True, False (False)

Description

When False, do not warp the mouse to the notice when it appears.

Resource:

notice.beepCount

Values:

N (1)

Description

Where N is an integer to specify how many times to ring the bell when a notice appears.

Resource:

OpenWindows.scrollbarPlacement (Props)

Values:

Left, Right (Right)

Description

When set to Left, put all scrollbars on the lefthand side of the window or object.

Resource:

OpenWindows.multiClickTimeout (Props)

Values:

N (4)

Description

Where N is an integer greater than 2. Set the number of tenths of a second between clicks for a multi-click. A click is button-down, button-up pair.

Resource:

text.delimiterChars

Values:

string (' \011!\"#$%&\'()*+,-./:;<=>?@[\\]^_`{|}~')

Description

This resource allows the user to select the delimiter characters that are used when doing word level selections in the XView package. It was added because of the needs of the international marketplace, and it allows the user to define the local delimiters for the character set that is being used with the current keyboard and Sun workstation. Note that the octal characters can be scrambled by Xrm during a rewrite of the value of text.delimiter.Chars. Xrm interprets the text.delimiterChar string when it is loaded. Specifically it will decode the backslashed portions of the string and convert them to octal representations. When this is passed to the client application, the logic will function correctly. However, this misbehavior of Xrm causes the string to be stored incorrectly if the user saves the .Xdefaults file using the Xrm content of the string. The specific problem(s) that occur are the stripping of the backslash characters and the expansion of the tab character (\011).

To correct this problem, one can put the text.delimiterChar entry into an .Xdefaults file that will not be overwritten when saving the workspace properties (for example, a system wide defaults file). Or a copy of the text.delimiterChar entry can be inserted after .Xdefaults file saves.

Resource:

scrollbar.jumpCursor (Props)

Values:

True, False (True)

Description

When False, the scrollbar will not move the mouse pointer when scrolling.

Resource:

scrollbar.repeatDelay

Values:

N (100)

Description

Where N is some integer greater than 2. Specifies the time in milliseconds when a click becomes a repeated action.

Resource:

scrollbar.pageInterval

Values:

N (100)

Description

Where N is some integer greater than 2. Specifies the time in milliseconds between repeats of a single page scroll.

Resource:

scrollbar.lineInterval

Values:

N (1)

Description

Where N is some integer greater than 0. Specifies the time in milliseconds between repeats of a single line scroll. How long to pause scrolling when holding down the SELECT button on the scrollbar elevator. Scrollbar sets up a timer routine for repeats.

Resource:

text.maxDocumentSize

Values:

N (2000)

Description

Where N specifies the bytes used in memory before a text file is saved to a file on disk. Once this limit is exceeded, the text package will send a notice to the user to tell them that no more insertions are possible. If the file being edited is saved to a file, or it is a disk file being edited, then the limit does not apply.

Resource:

text.retained

Values:

True, False (False)

Description

If True, retain text windows with server backing store.

Resource:

text.extrasMenuFilename

Values:

filename (/usr/lib/.text_extras_menu)

Description

Where filename is an absolute location to a file. Can also be set via environment variable EXTRASMENU. This file is used for the text package's Extras menu. The commands specified in the extras menu are applied to the contents of the current selection in the textsw window and then it inserts the results at the current insertion point.

Resource:

text.enableScrollbar

Values:

True, False (True)

Description

When False, do not put a scrollbar on textsw objects.

Resource:

text.againLimit

Values:

N (1)

Description

Where N is an integer between 0 and 500. Number of operations the "again history" remembers for a textsw.

Resource:

text.autoIndent

Values:

True, False (False)

Description

When True, begin the next line at the same indentation as the previous line as typing in text.

Resource:

text.autoScrollBy

Values:

N (1)

Description

Where N is an integer between 0 and 100. Specifies the number of lines to scroll when type-in moves insertion point below the view.

Resource:

text.confirmOverwrite

Values:

True, False (True)

Description

When False, do not give user confirmation if a save will overwrite an existing file.

Resource:

text.displayControlChars

Values:

True, False (True)

Description

When False, use an up arrow plus a letter to display the control character instead of the character that is available for the current font.

Resource:

Text.DeleteReplacesClipboard

Values:

True, False (False)

Description

This resource controls whether text that has been selected and then deleted by the delete key or replaced by any other keystroke will be copied to the clipboard. If the value is True, then the selected text will be copied to the clipboard. If the value is False, then the text selected does not replace the clipboard. This resource also applies to the text selected for the filter function. If the resource is True, then the text selected for a filter function will replace the clipboard when the filter successfully finishes. If the resource is False, then the text selected does not replace the clipboard.

Resource:

text.undoLimit

Values:

N (50 maximum of 500)

Description

Where N is an integer between 0 and 500. How many operations to save in the undo history log. These operations will be undone when you press the "Undo" key in the text window.

Resource:

text.insertMakesCaretVisible

Values:

If_auto_scroll (Always)

Description

Controls whether insertion causes repositioning to make inserted text visible.

Resource:

text.lineBreak

Values:

Clip, Wrap_char, Wrap_word (Wrap_word)

Description

Determines how the textsw treats file lines when they are too big to fit on one display line.

Resource:

text.margin.bottom

Values:

N (0)

Description

Where N is an integer between -1 and 50. Specifies the minimum number of lines to maintain between insertion point and bottom of view. A value of -1 turns auto scrolling off.

Resource:

mouse.multiclick.space

Values:

N (4)

Description

Where N is an integer between 2 and 500. Specifies the maximum number of pixels between successive mouse clicks to still have the clicks considered as a multi-click event.

Resource:

text.storeChangesFile

Values:

True, False (True)

Description

When False, do not change the name of the current file being edited to the name of the file that is stored. The name of the current file is reflected in the titlebar of the textedit frame.

Resource:

text.margin.top

Values:

N (2)

Description

Where N is an integer between -1 and 50. Specifies the minimum number of lines to maintain between the start of the selection and the top of the view. A value of -1 means defeat normal actions.

Resource:

text.margin.left

Values:

N (8)

Description

Where N is an integer between 0 and 2000. Specifies the margin in pixels that the text should maintain between the left hand border of the window and the first character on each line.

Resource:

text.margin.right

Values:

N (0)

Description

Where N is an integer between 0 and 2000. Specifies the margin in pixels that the text should maintain between the right hand border of the window and the last character on each line.

Resource:

text.tabWidth

Values:

N (8)

Description

Where N is an integer between 0 and 50. Specifies the width in characters of the tab character.

Resource:

Text.LineSpacing

Values:

N (0)

Description

Where N is an integer which is the percentage of the maximum height of a character in the Textsw window font to use as interline spacing. Setting Text.LineSpacing to a nonzero positive number will increase the size of a Textsw proportionally. xv_set() of WIN_ROWS will still yield the correct number of rows. However, the window will be taller as compared to a Textsw with Text.LineSpacing set to 0. This resource allows XView to conform to TUV requirements. To meet TUV requirements, set Text.LineSpacing to 15 or greater.

Resource:

term.boldStyle

Values:

None, Offset_X, Offset_Y, Offset_X_and_Y, Offset_XY, Offset_X_and_XY, Offset_Y_and_XY, Offset_X_and_Y_and_XY, Invert (Invert)

Description

Specify the text bolding style for a terminal based window.

Resource:

term.inverseStyle

Values:

Enable, Disable, Same_as_bold (Enable)

Description

Specify the text inverting style for a terminal based window.

Resource:

term.underlineStyle

Values:

Enable, Disable, Same_as_bold (Enable)

Description

Specify the text underlining style for a terminal based window.

Resource:

term.useAlternateTtyswrc

Values:

True, False (True)

Description

When True, and a $HOME/.ttyswrc is not found, look for an alternate ttyswrc file. When False, do not look for an alternate file is one is not found in the home directory, $HOME/.ttyswrc.

Resource:

term.alternateTtyswrc

Values:

filename ($XVIEWHOME/lib/.ttyswrc)

Description

Where filename specifies a complete filename and absolute path of an alternate ttyswrc file. This is only used if a .ttyswrc file is not found in $HOME/.ttyswrc and term.useAlternateTtyswrc is True.

Resource:

term.enableEdit

Values:

True, False (True)

Description

When False, do not keep an editlog of what has been typed into the term window. This is set to false automatically when switching from a scrollable term to one that is not scrollable.

Resource:

ttysw.eightBitOutput

Values:

True, False (True)

Description

This resource controls whether characters modified by the meta modifier are encoded as eight-bit characters when passed to the ttysw's pty or are delivered as seven-bit characters.

Resource:

ttysw.yieldModifiers

Values:

Meta, Alt (The default is to not remove any semantic meaning from any modifiers)

Description

This resource takes as a value a list of modifier keys. Any semantic meaning (mouseless command or keyboard accelerator) that would normally be associated with the listed modifiers when the keyboard focus is in a ttysw or termsw would be removed.

## ENVIRONMENT
$OPENWINHOME is the directory in which the server's directory hierarchy is installed.

$DISPLAY is the name of the server and screen to which applications should display.

$LD_LIBRARY_PATH is the SunOS shared library search path.

$HELPPATH is the path that applications will search for Open Look Help files.

## FILES
$OPENWINHOME/include/images

XView images

$OPENWINHOME/lib

XView Libraries

$OPENWINHOME/include

Include files

$OPENWINHOME/bin

Binaries

$OPENWINHOME/share/src/xview/demos

XView demo programs

$OPENWINHOME/share/src/xview/examples

XView example programs

## SEE ALSO
openwin(1), xnews(1), xlsfonts(1), xmodmap(1), iconedit(1)


package: libyaz

title: bib1-attr(7)

summary: Bib\-1 Attribute Set

text:
# bib1-attr(7)

## NAME
bib1-attr - Bib-1 Attribute Set

## DESCRIPTION
This reference entry lists the Bib-1 attribute set types and values.

## TYPES
The Bib-1 attribute set defines six attribute types: Use (1), Relation (2), Position (3), Structure (4), Truncation (5) and Completeness (6).

## USE (1)

```
    1     Personal-name

    2     Corporate-name

    3     Conference-name

    4     Title

    5     Title-series

    6     Title-uniform

    7     ISBN

    8     ISSN

    9     LC-card-number

    10    BNB-card-number

    11    BGF-number

    12    Local-number

    13    Dewey-classification

    14    UDC-classification

    15    Bliss-classification

    16    LC-call-number

    17    NLM-call-number

    18    NAL-call-number

    19    MOS-call-number

    20    Local-classification

    21    Subject-heading

    22    Subject-Rameau

    23    BDI-index-subject

    24    INSPEC-subject

    25    MESH-subject

    26    PA-subject

    27    LC-subject-heading

    28    RVM-subject-heading

    29    Local-subject-index

    30    Date

    31    Date-of-publication

    32    Date-of-acquisition

    33    Title-key

    34    Title-collective

    35    Title-parallel

    36    Title-cover

    37    Title-added-title-page

    38    Title-caption

    39    Title-running

    40    Title-spine

    41    Title-other-variant

    42    Title-former

    43    Title-abbreviated

    44    Title-expanded

    45    Subject-precis

    46    Subject-rswk

    47    Subject-subdivision

    48    Number-natl-biblio

    49    Number-legal-deposit

    50    Number-govt-pub

    51    Number-music-publisher

    52    Number-db

    53    Number-local-call

    54    Code-language

    55    Code-geographic

    56    Code-institution

    57    Name-and-title

    58    Name-geographic

    59    Place-publication

    60    CODEN

    61    Microform-generation

    62    Abstract

    63    Note

    1000  Author-title

    1001  Record-type

    1002  Name

    1003  Author

    1004  Author-name-personal

    1005  Author-name-corporate

    1006  Author-name-conference

    1007  Identifier-standard

    1008  Subject-LC-childrens

    1009  Subject-name-personal

    1010  Body-of-text

    1011  Date/time-added-to-db

    1012  Date/time-last-modified

    1013  Authority/format-id

    1014  Concept-text

    1015  Concept-reference

    1016  Any

    1017  Server-choice

    1018  Publisher

    1019  Record-source

    1020  Editor

    1021  Bib-level

    1022  Geographic-class

    1023  Indexed-by

    1024  Map-scale

    1025  Music-key

    1026  Related-periodical

    1027  Report-number

    1028  Stock-number

    1030  Thematic-number

    1031  Material-type

    1032  Doc-id

    1033  Host-item

    1034  Content-type

    1035  Anywhere

    1036  Author-Title-Subject

```

## RELATION (2)

```
    1 Less than

    2 Less than or equal

    3 Equal

    4 Greater or equal

    5 Greater than

    6 Not equal

    100 Phonetic

    101 Stem

    102 Relevance

    103 AlwaysMatches

```

## POSITION (3)

```
    1 First in field

    2 First in subfield

    3 Any position in field

```

## STRUCTURE (4)

```
    1 Phrase

    2 Word

    3 Key

    4 Year

    5 Date (normalized)

    6 Word list

    100 Date (un-normalized)

    101 Name (normalized)

    102 Name (un-normalized)

    103 Structure

    104 Urx

    105 Free-form-text

    106 Document-text

    107 Local-number

    108 String

    109 Numeric-string

```

## TRUNCATION (5)

```
    1 Right truncation

    2 Left truncation

    3 Left and right truncation

    100 Do not truncate

    101 Process # in search term  . regular #=.*

    102 RegExpr-1

    103 RegExpr-2

    104 Process # ?n . regular: #=., ?n=.{0,n} or ?=.* Z39.58

```

Thw 105-106 truncation attributes below are only supported by Index Data's Zebra server.

```
    105 Process * ! regular: *=.*, !=. and right truncate

    106 Process * ! regular: *=.*, !=.

```

## COMPLETENESS (6)

```
    1 Incomplete subfield

    2 Complete subfield

    3 Complete field

```

## SORTING (7)

```
    1 ascending

    2 descending

```

Type 7 is an Index Data extension to RPN queries that allows embedding a sort critieria into a query.

## SEE ALSO
Bib-1 Attribute Set[1]

Attibute Set Bib-1 Semantics[2].

## AUTHORS
Index Data

## NOTES
1.

Bib-1 Attribute Set

http://www.loc.gov/z3950/agency/defns/bib1.html

2.

Attibute Set Bib-1 Semantics

http://www.loc.gov/z3950/agency/bib1.html


yaz

title: yaz(7)

summary: Z39.50 toolkit.

text:
# yaz(7)

## NAME
yaz - Z39.50 toolkit.

## DESCRIPTION
YAZ is a C/C++ programmer's toolkit supporting the development of Z39.50v3 clients and servers. The YAZ toolkit offers several different levels of access to the ISO23950/Z39.50, SRU Solr (client only) and ILL protocols. The level that you need to use depends on your requirements, and the role (server or client) that you want to implement.

## COPYRIGHT
Copyright © 1995-2018 Index Data.

All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

•Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

•Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

•Neither the name of Index Data nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS AND CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

## SEE ALSO
yaz-client(1), yaz-ztest(8), yaz-config(8), zoomsh(1) bib1-attr(7)

YAZ manual ( /usr/share/doc/yaz)

YAZ home page[1].

Z39.50 Maintenance Agency Page[2].

## AUTHORS
Index Data

## NOTES
1.

YAZ home page

http://www.indexdata.com/yaz

2.

Z39.50 Maintenance Agency Page

http://www.loc.gov/z3950/agency/


zmq

package: libzeromq

title: zmq(7)

summary: 0MQ lightweight messaging kernel

text:
# zmq(7)

## NAME
zmq - 0MQ lightweight messaging kernel

## SYNOPSIS
\#include <zmq.h>

cc [flags] files -lzmq [libraries]

## DESCRIPTION
The 0MQ lightweight messaging kernel is a library which extends the standard socket interfaces with features traditionally provided by specialised messaging middleware products. 0MQ sockets provide an abstraction of asynchronous message queues, multiple messaging patterns, message filtering (subscriptions), seamless access to multiple transport protocols and more.

This documentation presents an overview of 0MQ concepts, describes how 0MQ abstracts standard sockets and provides a reference manual for the functions provided by the 0MQ library.

### Context
The 0MQ context keeps the list of sockets and manages the async I/O thread and internal queries.

Before using any 0MQ library functions you must create a 0MQ context. When you exit your application you must destroy the context. These functions let you work with contexts:

Create a new 0MQ context

zmq_ctx_new(3)

Work with context properties

zmq_ctx_set(3) zmq_ctx_get(3)

Destroy a 0MQ context

zmq_ctx_shutdown(3) zmq_ctx_term(3)

Thread safety

A 0MQ context is thread safe and may be shared among as many application threads as necessary, without any additional locking required on the part of the caller.

Individual 0MQ sockets are not thread safe except in the case where full memory barriers are issued when migrating a socket from one thread to another. In practice this means applications can create a socket in one thread with zmq_socket() and then pass it to a newly created thread as part of thread initialisation, for example via a structure passed as an argument to pthread_create().

Multiple contexts

Multiple contexts may coexist within a single application. Thus, an application can use 0MQ directly and at the same time make use of any number of additional libraries or components which themselves make use of 0MQ as long as the above guidelines regarding thread safety are adhered to.

### Messages
A 0MQ message is a discrete unit of data passed between applications or components of the same application. 0MQ messages have no internal structure and from the point of view of 0MQ itself they are considered to be opaque binary data.

The following functions are provided to work with messages:

Initialise a message

zmq_msg_init(3) zmq_msg_init_size(3) zmq_msg_init_buffer(3) zmq_msg_init_data(3)

Sending and receiving a message

zmq_msg_send(3) zmq_msg_recv(3)

Release a message

zmq_msg_close(3)

Access message content

zmq_msg_data(3) zmq_msg_size(3) zmq_msg_more(3)

Work with message properties

zmq_msg_gets(3) zmq_msg_get(3) zmq_msg_set(3)

Message manipulation

zmq_msg_copy(3) zmq_msg_move(3)

### Sockets
0MQ sockets present an abstraction of an asynchronous message queue, with the exact queueing semantics depending on the socket type in use. See zmq_socket(3) for the socket types provided.

The following functions are provided to work with sockets:

Creating a socket

zmq_socket(3)

Closing a socket

zmq_close(3)

Manipulating socket options

zmq_getsockopt(3) zmq_setsockopt(3)

Establishing a message flow

zmq_bind(3) zmq_connect(3)

Sending and receiving messages

zmq_msg_send(3) zmq_msg_recv(3) zmq_send(3) zmq_recv(3) zmq_send_const(3)

Monitoring socket events

zmq_socket_monitor(3)

Input/output multiplexing. 0MQ provides a mechanism for applications to multiplex input/output events over a set containing both 0MQ sockets and standard sockets. This mechanism mirrors the standard poll() system call, and is described in detail in zmq_poll(3). This API is deprecated, however.

There is a new DRAFT API with multiple zmq_poller_* function, which is described in zmq_poller(3).

### Transports
A 0MQ socket can use multiple different underlying transport mechanisms. Each transport mechanism is suited to a particular purpose and has its own advantages and drawbacks.

The following transport mechanisms are provided:

Unicast transport using TCP

zmq_tcp(7)

Reliable multicast transport using PGM

zmq_pgm(7)

Local inter-process communication transport

zmq_ipc(7)

Local in-process (inter-thread) communication transport

zmq_inproc(7)

Virtual Machine Communications Interface (VMC) transport

zmq_vmci(7)

Unreliable unicast and multicast using UDP

zmq_udp(7)

### Proxies
0MQ provides proxies to create fanout and fan-in topologies. A proxy connects a frontend socket to a backend socket and switches all messages between the two sockets, opaquely. A proxy may optionally capture all traffic to a third socket. To start a proxy in an application thread, use zmq_proxy(3).

### Security
A 0MQ socket can select a security mechanism. Both peers must use the same security mechanism.

The following security mechanisms are provided for IPC and TCP connections:

Null security

zmq_null(7)

Plain-text authentication using username and password

zmq_plain(7)

Elliptic curve authentication and encryption

zmq_curve(7)

Generate a CURVE keypair in armored text format

zmq_curve_keypair(3)

Derive a CURVE public key from a secret key: zmq_curve_public(3)

Converting keys to/from armoured text strings

zmq_z85_decode(3) zmq_z85_encode(3)

## ERROR HANDLING
The 0MQ library functions handle errors using the standard conventions found on POSIX systems. Generally, this means that upon failure a 0MQ library function shall return either a NULL value (if returning a pointer) or a negative value (if returning an integer), and the actual error code shall be stored in the errno variable.

On non-POSIX systems some users may experience issues with retrieving the correct value of the errno variable. The zmq_errno() function is provided to assist in these cases; for details refer to zmq_errno(3).

The zmq_strerror() function is provided to translate 0MQ-specific error codes into error message strings; for details refer to zmq_strerror(3).

## UTILITY
The following utility functions are provided:

Working with atomic counters

zmq_atomic_counter_new(3) zmq_atomic_counter_set(3) zmq_atomic_counter_inc(3) zmq_atomic_counter_dec(3) zmq_atomic_counter_value(3) zmq_atomic_counter_destroy(3)

## MISCELLANEOUS
The following miscellaneous functions are provided:

Report 0MQ library version

zmq_version(3)

## LANGUAGE BINDINGS
The 0MQ library provides interfaces suitable for calling from programs in any language; this documentation documents those interfaces as they would be used by C programmers. The intent is that programmers using 0MQ from other languages shall refer to this documentation alongside any documentation provided by the vendor of their language binding.

Language bindings (C++, Python, PHP, Ruby, Java and more) are provided by members of the 0MQ community and pointers can be found on the 0MQ website.

## AUTHORS
This page was written by the 0MQ community. To make a change please read the 0MQ Contribution Policy at http://www.zeromq.org/docs:contributing.

## RESOURCES
Main web site: http://www.zeromq.org/

Report bugs to the 0MQ development mailing list: <zeromq-dev@lists.zeromq.org[1]>

## COPYING
Free use of this software is granted under the terms of the GNU Lesser General Public License (LGPL). For details see the files COPYING and COPYING.LESSER included with the 0MQ distribution.

## NOTES
1.

zeromq-dev@lists.zeromq.org

mailto:zeromq-dev@lists.zeromq.org


package: libzeromq-devel

title: zmq_curve(7)

text:
# zmq_curve(7)

## NAME
zmq_curve - secure authentication and confidentiality

## SYNOPSIS
The CURVE mechanism defines a mechanism for secure authentication and confidentiality for communications between a client and a server. CURVE is intended for use on public networks. The CURVE mechanism is defined by this document: http://rfc.zeromq.org/spec:25.

## CLIENT AND SERVER ROLES
A socket using CURVE can be either client or server, at any moment, but not both. The role is independent of bind/connect direction.

A socket can change roles at any point by setting new options. The role affects all zmq_connect and zmq_bind calls that follow it.

To become a CURVE server, the application sets the ZMQ_CURVE_SERVER option on the socket, and then sets the ZMQ_CURVE_SECRETKEY option to provide the socket with its long-term secret key. The application does not provide the socket with its long-term public key, which is used only by clients.

To become a CURVE client, the application sets the ZMQ_CURVE_SERVERKEY option with the long-term public key of the server it intends to connect to, or accept connections from, next. The application then sets the ZMQ_CURVE_PUBLICKEY and ZMQ_CURVE_SECRETKEY options with its client long-term key pair.

If the server does authentication it will be based on the client’s long term public key.

## KEY ENCODING
The standard representation for keys in source code is either 32 bytes of base 256 (binary) data, or 40 characters of base 85 data encoded using the Z85 algorithm defined by http://rfc.zeromq.org/spec:32.

The Z85 algorithm is designed to produce printable key strings for use in configuration files, the command line, and code. There is a reference implementation in C at https://github.com/zeromq/rfc/tree/master/src.

## TEST KEY VALUES
For test cases, the client shall use this long-term key pair (specified as hexadecimal and in Z85):

```
public:

    BB88471D65E2659B30C55A5321CEBB5AAB2B70A398645C26DCA2B2FCB43FC518

    Yne@$w-vo<fVvi]a<NY6T1ed:M$fCG*[IaLV{hID
secret:

    7BB864B489AFA3671FBE69101F94B38972F24816DFB01B51656B3FEC8DFD0888

    D:)Q[IlAW!ahhC2ac:9*A}h:p?([4%wOTJ%JR%cs
```

And the server shall use this long-term key pair (specified as hexadecimal and in Z85):

```
public:

    54FCBA24E93249969316FB617C872BB0C1D1FF14800427C594CBFACF1BC2D652

    rq:rM>}U?@Lns47E1%kR.o@n%FcmmsL/@{H8]yf7
secret:

    8E0BDD697628B91D8F245587EE95C5B04D48963F79259877B49CD9063AEAD3B7

    JTKVSB%%)wK0E.X)V>+}o?pNmC{O&4W4b!Ni{Lh6
```

## SEE ALSO
zmq_z85_encode(3) zmq_z85_decode(3) zmq_setsockopt(3) zmq_null(7) zmq_plain(7) zmq(7)

## AUTHORS
This page was written by the 0MQ community. To make a change please read the 0MQ Contribution Policy at http://www.zeromq.org/docs:contributing.


title: zmq_gssapi(7)

text:
# zmq_gssapi(7)

## NAME
zmq_gssapi - secure authentication and confidentiality

## SYNOPSIS
The GSSAPI mechanism defines a mechanism for secure authentication and confidentiality for communications between a client and a server using the Generic Security Service Application Program Interface (GSSAPI). The GSSAPI mechanism can be used on both public and private networks. GSSAPI itself is defined in IETF RFC-2743: http://tools.ietf.org/html/rfc2743. The ZeroMQ GSSAPI mechanism is defined by this document: http://rfc.zeromq.org/spec:38.

## CLIENT AND SERVER ROLES
A socket using GSSAPI can be either client or server, but not both.

To become a GSSAPI server, the application sets the ZMQ_GSSAPI_SERVER option on the socket.

To become a GSSAPI client, the application sets the ZMQ_GSSAPI_SERVICE_PRINCIPAL option to the name of the principal on the server to which it intends to connect.

On client or server, the application may additionally set the ZMQ_GSSAPI_PRINCIPAL option to provide the socket with the name of the principal for whom GSSAPI credentials should be acquired. If this option is not set, default credentials are used.

## OPTIONAL ENCRYPTION
By default, the GSSAPI mechanism will encrypt all communications between client and server. If encryption is not desired (e.g. on private networks), the client and server applications can disable it by setting the ZMQ_GSSAPI_PLAINTEXT option. Both the client and server must set this option to the same value.

## PRINCIPAL NAMES
Principal names specified with the ZMQ_GSSAPI_SERVICE_PRINCIPAL or ZMQ_GSSAPI_PRINCIPAL options are interpreted as "host based" name types by default. The ZMQ_GSSAPI_PRINCIPAL_NAMETYPE and ZMQ_GSSAPI_SERVICE_PRINCIPAL_NAMETYPE options may be used to change the name type to one of:

ZMQ_GSSAPI_NT_HOSTBASED

The name should be of the form "service" or "service@hostname", which will parse into a principal of "service/hostname" in the local realm. This is the default name type.

ZMQ_GSSAPI_NT_USER_NAME

The name should be a local username, which will parse into a single-component principal in the local realm.

ZMQ_GSSAPI_NT_KRB5_PRINCIPAL

The name is a principal name string. This name type only works with the krb5 GSSAPI mechanism.

## SEE ALSO
zmq_setsockopt(3) zmq_null(7) zmq_curve(7) zmq(7)

## AUTHORS
This page was written by the 0MQ community. To make a change please read the 0MQ Contribution Policy at http://www.zeromq.org/docs:contributing.


title: zmq_inproc(7)

summary: 0MQ local in\-process (inter\-thread) communication transport

text:
# zmq_inproc(7)

## NAME
zmq_inproc - 0MQ local in-process (inter-thread) communication transport

## SYNOPSIS
The in-process transport passes messages via memory directly between threads sharing a single 0MQ context.

Note No I/O threads are involved in passing messages using the inproc transport. Therefore, if you are using a 0MQ context for in-process messaging only you can initialise the context with zero I/O threads. See zmq_init(3) for details.

## ADDRESSING
A 0MQ endpoint is a string consisting of a transport:// followed by an address. The transport specifies the underlying protocol to use. The address specifies the transport-specific address to connect to.

For the in-process transport, the transport is inproc, and the meaning of the address part is defined below.

### Assigning a local address to a socket
When assigning a local address to a socket using zmq_bind() with the inproc transport, the endpoint shall be interpreted as an arbitrary string identifying the name to create. The name must be unique within the 0MQ context associated with the socket and may be up to 256 characters in length. No other restrictions are placed on the format of the name.

### Connecting a socket
When connecting a socket to a peer address using zmq_connect() with the inproc transport, the endpoint shall be interpreted as an arbitrary string identifying the name to connect to. Before version 4.0 he name must have been previously created by assigning it to at least one socket within the same 0MQ context as the socket being connected. Since version 4.0 the order of zmq_bind() and zmq_connect() does not matter just like for the tcp transport type.

## EXAMPLES
Assigning a local address to a socket.

```
//  Assign the in-process name "#1"
rc = zmq_bind(socket, "inproc://#1");
assert (rc == 0);
//  Assign the in-process name "my-endpoint"
rc = zmq_bind(socket, "inproc://my-endpoint");
assert (rc == 0);
```

Connecting a socket.

```
//  Connect to the in-process name "#1"
rc = zmq_connect(socket, "inproc://#1");
assert (rc == 0);
//  Connect to the in-process name "my-endpoint"
rc = zmq_connect(socket, "inproc://my-endpoint");
assert (rc == 0);
```

## SEE ALSO
zmq_bind(3) zmq_connect(3) zmq_ipc(7) zmq_tcp(7) zmq_pgm(7) zmq_vmci(7) zmq(7)

## AUTHORS
This page was written by the 0MQ community. To make a change please read the 0MQ Contribution Policy at http://www.zeromq.org/docs:contributing.


title: zmq_ipc(7)

summary: 0MQ local inter\-process communication transport

text:
# zmq_ipc(7)

## NAME
zmq_ipc - 0MQ local inter-process communication transport

## SYNOPSIS
The inter-process transport passes messages between local processes using a system-dependent IPC mechanism.

Note The inter-process transport is currently only implemented on operating systems that provide UNIX domain sockets.

## ADDRESSING
A 0MQ endpoint is a string consisting of a transport:// followed by an address. The transport specifies the underlying protocol to use. The address specifies the transport-specific address to connect to.

For the inter-process transport, the transport is ipc, and the meaning of the address part is defined below.

### Binding a socket
When binding a socket to a local address using zmq_bind() with the ipc transport, the endpoint shall be interpreted as an arbitrary string identifying the pathname to create. The pathname must be unique within the operating system namespace used by the ipc implementation, and must fulfill any restrictions placed by the operating system on the format and length of a pathname.

When the address is wild-card *, zmq_bind() shall generate a unique temporary pathname. The caller should retrieve this pathname using the ZMQ_LAST_ENDPOINT socket option. See zmq_getsockopt(3) for details.

Note any existing binding to the same endpoint shall be overridden. That is, if a second process binds to an endpoint already bound by a process, this will succeed and the first process will lose its binding. In this behaviour, the ipc transport is not consistent with the tcp or inproc transports.

Note the endpoint pathname must be writable by the process. When the endpoint starts with /, e.g., ipc:///pathname, this will be an absolute pathname. If the endpoint specifies a directory that does not exist, the bind shall fail.

Note on Linux only, when the endpoint pathname starts with @, the abstract namespace shall be used. The abstract namespace is independent of the filesystem and if a process attempts to bind an endpoint already bound by a process, it will fail. See unix(7) for details.

Note IPC pathnames have a maximum size that depends on the operating system. On Linux, the maximum is 113 characters including the "ipc://" prefix (107 characters for the real path name).

### Unbinding wild-card address from a socket
When wild-card * endpoint was used in zmq_bind(), the caller should use real endpoint obtained from the ZMQ_LAST_ENDPOINT socket option to unbind this endpoint from a socket using zmq_unbind().

### Connecting a socket
When connecting a socket to a peer address using zmq_connect() with the ipc transport, the endpoint shall be interpreted as an arbitrary string identifying the pathname to connect to. The pathname must have been previously created within the operating system namespace by assigning it to a socket with zmq_bind().

## EXAMPLES
Assigning a local address to a socket.

```
//  Assign the pathname "/tmp/feeds/0"
rc = zmq_bind(socket, "ipc:///tmp/feeds/0");
assert (rc == 0);
```

Connecting a socket.

```
//  Connect to the pathname "/tmp/feeds/0"
rc = zmq_connect(socket, "ipc:///tmp/feeds/0");
assert (rc == 0);
```

## SEE ALSO
zmq_bind(3) zmq_connect(3) zmq_inproc(7) zmq_tcp(7) zmq_pgm(7) zmq_vmci(7) zmq_getsockopt(3) zmq(7)

## AUTHORS
This page was written by the 0MQ community. To make a change please read the 0MQ Contribution Policy at http://www.zeromq.org/docs:contributing.


title: zmq_null(7)

summary: no security or confidentiality

text:
# zmq_null(7)

## NAME
zmq_null - no security or confidentiality

## SYNOPSIS
The NULL mechanism is defined by the ZMTP 3.0 specification: http://rfc.zeromq.org/spec:23. This is the default security mechanism for ZeroMQ sockets.

## SEE ALSO
zmq_plain(7) zmq_curve(7) zmq(7)

## AUTHORS
This page was written by the 0MQ community. To make a change please read the 0MQ Contribution Policy at http://www.zeromq.org/docs:contributing.


title: zmq_pgm(7)

text:
# zmq_pgm(7)

## NAME
zmq_pgm - 0MQ reliable multicast transport using PGM

## SYNOPSIS
PGM (Pragmatic General Multicast) is a protocol for reliable multicast transport of data over IP networks.

## DESCRIPTION
0MQ implements two variants of PGM, the standard protocol where PGM datagrams are layered directly on top of IP datagrams as defined by RFC 3208 (the pgm transport) and "Encapsulated PGM" or EPGM where PGM datagrams are encapsulated inside UDP datagrams (the epgm transport).

The pgm and epgm transports can only be used with the ZMQ_PUB and ZMQ_SUB socket types.

Further, PGM sockets are rate limited by default. For details, refer to the ZMQ_RATE, and ZMQ_RECOVERY_IVL options documented in zmq_setsockopt(3).

Caution The pgm transport implementation requires access to raw IP sockets. Additional privileges may be required on some operating systems for this operation. Applications not requiring direct interoperability with other PGM implementations are encouraged to use the epgm transport instead which does not require any special privileges.

## ADDRESSING
A 0MQ endpoint is a string consisting of a transport:// followed by an address. The transport specifies the underlying protocol to use. The address specifies the transport-specific address to connect to.

For the PGM transport, the transport is pgm, and for the EPGM protocol the transport is epgm. The meaning of the address part is defined below.

### Connecting a socket
When connecting a socket to a peer address using zmq_connect() with the pgm or epgm transport, the endpoint shall be interpreted as an interface followed by a semicolon, followed by a multicast address, followed by a colon and a port number.

An interface may be specified by either of the following:

•The interface name as defined by the operating system.

•The primary IPv4 address assigned to the interface, in its numeric representation.

Note Interface names are not standardised in any way and should be assumed to be arbitrary and platform dependent. On Win32 platforms no short interface names exist, thus only the primary IPv4 address may be used to specify an interface. The interface part can be omitted, in that case the default one will be selected.

A multicast address is specified by an IPv4 multicast address in its numeric representation.

## WIRE FORMAT
Consecutive PGM datagrams are interpreted by 0MQ as a single continuous stream of data where 0MQ messages are not necessarily aligned with PGM datagram boundaries and a single 0MQ message may span several PGM datagrams. This stream of data consists of 0MQ messages encapsulated in frames as described in zmq_tcp(7).

### PGM datagram payload
The following ABNF grammar represents the payload of a single PGM datagram as used by 0MQ:

```
datagram               = (offset data)
offset                 = 2OCTET
data                   = *OCTET
```

In order for late joining consumers to be able to identify message boundaries, each PGM datagram payload starts with a 16-bit unsigned integer in network byte order specifying either the offset of the first message frame in the datagram or containing the value 0xFFFF if the datagram contains solely an intermediate part of a larger message.

Note that offset specifies where the first message begins rather than the first message part. Thus, if there are trailing message parts at the beginning of the packet the offset ignores them and points to first initial message part in the packet.

The following diagram illustrates the layout of a single PGM datagram payload:

```
+------------------+----------------------+
| offset (16 bits) |         data         |
+------------------+----------------------+
```

The following diagram further illustrates how three example 0MQ frames are laid out in consecutive PGM datagram payloads:

```
First datagram payload
+--------------+-------------+---------------------+
| Frame offset |   Frame 1   |   Frame 2, part 1   |
|    0x0000    | (Message 1) | (Message 2, part 1) |
+--------------+-------------+---------------------+
Second datagram payload
+--------------+---------------------+
| Frame offset |   Frame 2, part 2   |
| 0xFFFF       | (Message 2, part 2) |
+--------------+---------------------+
Third datagram payload
+--------------+----------------------------+-------------+
| Frame offset |   Frame 2, final 8 bytes   |   Frame 3   |
| 0x0008       | (Message 2, final 8 bytes) | (Message 3) |
+--------------+----------------------------+-------------+
```

## CONFIGURATION
The PGM is protocol is capable of multicasting data at high rates (500Mbps+) with large messages (1MB+), however it requires setting the relevent ZMQ socket options that are documented in zmq_setsockopt(3):

•The ZMQ_RATE should be set sufficiently high, e.g. 1Gbps

•The ZMQ_RCVBUF should be increased on the subscriber, e.g. 4MB

•The ZMQ_SNDBUF should be increased on the publisher, e.g. 4MB

It’s important to note that the ZMQ_RCVBUF and ZMQ_SNDBUF options are limited by the underlying host OS tx/rx buffer size limit. On linux, these can be increased for the current session with the following commands:

```
# set tx/rx buffers to 4MB (default can also be read as the initial buffer size)
sudo sysctl -w net.core.rmem_max=4194304
sudo sysctl -w net.core.wmem_max=4194304
sudo sysctl -w net.core.rmem_default=4194304
sudo sysctl -w net.core.wmem_default=4194304
```

## EXAMPLE
Connecting a socket.

```
//  Connecting to the multicast address 239.192.1.1, port 5555,
//  using the first Ethernet network interface on Linux
//  and the Encapsulated PGM protocol
rc = zmq_connect(socket, "epgm://eth0;239.192.1.1:5555");
assert (rc == 0);
//  Connecting to the multicast address 239.192.1.1, port 5555,
//  using the network interface with the address 192.168.1.1
//  and the standard PGM protocol
rc = zmq_connect(socket, "pgm://192.168.1.1;239.192.1.1:5555");
assert (rc == 0);
```

## SEE ALSO
zmq_connect(3) zmq_setsockopt(3) zmq_tcp(7) zmq_ipc(7) zmq_inproc(7) zmq_vmci(7) zmq(7)

## AUTHORS
This page was written by the 0MQ community. To make a change please read the 0MQ Contribution Policy at http://www.zeromq.org/docs:contributing.


title: zmq_plain(7)

summary: clear\-text authentication

text:
# zmq_plain(7)

## NAME
zmq_plain - clear-text authentication

## SYNOPSIS
The PLAIN mechanism defines a simple username/password mechanism that lets a server authenticate a client. PLAIN makes no attempt at security or confidentiality. It is intended for use on internal networks where security requirements are low. The PLAIN mechanism is defined by this document: http://rfc.zeromq.org/spec:24.

## USAGE
To use PLAIN, the server shall set the ZMQ_PLAIN_SERVER option, and the client shall set the ZMQ_PLAIN_USERNAME and ZMQ_PLAIN_PASSWORD socket options. Which peer binds, and which connects, is not relevant.

## SEE ALSO
zmq_setsockopt(3) zmq_null(7) zmq_curve(7) zmq(7)

## AUTHORS
This page was written by the 0MQ community. To make a change please read the 0MQ Contribution Policy at http://www.zeromq.org/docs:contributing.


title: zmq_tcp(7)

summary: 0MQ unicast transport using TCP

text:
# zmq_tcp(7)

## NAME
zmq_tcp - 0MQ unicast transport using TCP

## SYNOPSIS
TCP is an ubiquitous, reliable, unicast transport. When connecting distributed applications over a network with 0MQ, using the TCP transport will likely be your first choice.

## ADDRESSING
A 0MQ endpoint is a string consisting of a transport:// followed by an address. The transport specifies the underlying protocol to use. The address specifies the transport-specific address to connect to.

For the TCP transport, the transport is tcp, and the meaning of the address part is defined below.

### Assigning a local address to a socket
When assigning a local address to a socket using zmq_bind() with the tcp transport, the endpoint shall be interpreted as an interface followed by a colon and the TCP port number to use.

An interface may be specified by either of the following:

•The wild-card *, meaning all available interfaces.

•The primary IPv4 or IPv6 address assigned to the interface, in its numeric representation.

•The non-portable interface name as defined by the operating system.

The TCP port number may be specified by:

•A numeric value, usually above 1024 on POSIX systems.

•The wild-card *, meaning a system-assigned ephemeral port.

When using ephemeral ports, the caller should retrieve the actual assigned port using the ZMQ_LAST_ENDPOINT socket option. See zmq_getsockopt(3) for details.

### Unbinding wild-card address from a socket
When wild-card * endpoint was used in zmq_bind(), the caller should use real endpoint obtained from the ZMQ_LAST_ENDPOINT socket option to unbind this endpoint from a socket using zmq_unbind().

### Connecting a socket
When connecting a socket to a peer address using zmq_connect() with the tcp transport, the endpoint shall be interpreted as a peer address followed by a colon and the TCP port number to use. You can optionally specify a source_endpoint which will be used as the source address for your connection; tcp://source_endpoint;'endpoint', see the interface description above for details.

A peer address may be specified by either of the following:

•The DNS name of the peer.

•The IPv4 or IPv6 address of the peer, in its numeric representation.

Note: A description of the ZeroMQ Message Transport Protocol (ZMTP) which is used by the TCP transport can be found at http://rfc.zeromq.org/spec:15

## HWM
For the TCP transport, the high water mark (HWM) mechanism works in conjunction with the TCP socket buffers handled at OS level. Depending on the OS and several other factors the size of such TCP buffers will be different. Moreover TCP buffers provided by the OS will accomodate a varying number of messages depending on the size of messages (unlike ZMQ HWM settings the TCP socket buffers are measured in bytes and not messages).

This may result in apparently inexplicable behaviors: e.g., you may expect that setting ZMQ_SNDHWM to 100 on a socket using TCP transport will have the effect of blocking the transmission of the 101-th message if the receiver is slow. This is very unlikely when using TCP transport since OS TCP buffers will typically provide enough buffering to allow you sending much more than 100 messages.

Of course if the receiver is slow, transmitting on a TCP ZMQ socket will eventually trigger the "mute state" of the socket; simply don’t rely on the exact HWM value.

Obviously the same considerations apply for the receive HWM (see ZMQ_RCVHWM).

## EXAMPLES
Assigning a local address to a socket.

```
//  TCP port 5555 on all available interfaces
rc = zmq_bind(socket, "tcp://*:5555");
assert (rc == 0);
//  TCP port 5555 on the local loop-back interface on all platforms
rc = zmq_bind(socket, "tcp://127.0.0.1:5555");
assert (rc == 0);
//  TCP port 5555 on the first Ethernet network interface on Linux
rc = zmq_bind(socket, "tcp://eth0:5555");
assert (rc == 0);
```

Connecting a socket.

```
//  Connecting using an IP address
rc = zmq_connect(socket, "tcp://192.168.1.1:5555");
assert (rc == 0);
//  Connecting using a DNS name
rc = zmq_connect(socket, "tcp://server1:5555");
assert (rc == 0);
//  Connecting using a DNS name and bind to eth1
rc = zmq_connect(socket, "tcp://eth1:0;server1:5555");
assert (rc == 0);
//  Connecting using a IP address and bind to an IP address
rc = zmq_connect(socket, "tcp://192.168.1.17:5555;192.168.1.1:5555");
assert (rc == 0);
```

## SEE ALSO
zmq_bind(3) zmq_connect(3) zmq_pgm(7) zmq_ipc(7) zmq_inproc(7) zmq_vmci(7) zmq(7)

## AUTHORS
This page was written by the 0MQ community. To make a change please read the 0MQ Contribution Policy at http://www.zeromq.org/docs:contributing.


title: zmq_tipc(7)

summary: 0MQ unicast transport using TIPC

text:
# zmq_tipc(7)

## NAME
zmq_tipc - 0MQ unicast transport using TIPC

## SYNOPSIS
TIPC is a cluster IPC protocol with a location transparent addressing scheme.

## ADDRESSING
A 0MQ endpoint is a string consisting of a transport:// followed by an address. The transport specifies the underlying protocol to use. The address specifies the transport-specific address to connect to.

For the TIPC transport, the transport is tipc, and the meaning of the address part is defined below.

### Assigning a port name to a socket
When assigning a port name to a socket using zmq_bind() with the tipc transport, the endpoint is defined in the form: {type, lower, upper}

•Type is the numerical (u32) ID of your service.

•Lower and Upper specify a range for your service.

Publishing the same service with overlapping lower/upper ID’s will cause connection requests to be distributed over these in a round-robin manner.

### Connecting a socket
When connecting a socket to a peer address using zmq_connect() with the tipc transport, the endpoint shall be interpreted as a service ID, followed by a comma and the instance ID.

The instance ID must be within the lower/upper range of a published port name for the endpoint to be valid.

## EXAMPLES
Assigning a local address to a socket.

```
//  Publish TIPC service ID 5555
rc = zmq_bind(socket, "tipc://{5555,0,0}");
assert (rc == 0);
//  Publish TIPC service ID 5555 with a service range of 0-100
rc = zmq_bind(socket, "tipc://{5555,0,100}");
assert (rc == 0);
```

Connecting a socket.

```
//  Connect to service 5555 instance id 50
rc = zmq_connect(socket, "tipc://{5555,50}");
assert (rc == 0);
```

## SEE ALSO
zmq_bind(3) zmq_connect(3) zmq_tcp(7) zmq_pgm(7) zmq_ipc(7) zmq_inproc(7) zmq_vmci(7) zmq(7)

## AUTHORS
This page was written by the 0MQ community. To make a change please read the 0MQ Contribution Policy at http://www.zeromq.org/docs:contributing.


title: zmq_udp(7)

summary: 0MQ UDP multicast and unicast transport

text:
# zmq_udp(7)

## NAME
zmq_udp - 0MQ UDP multicast and unicast transport

## SYNOPSIS
UDP is unreliable protocol transport of data over IP networks. UDP support both unicast and multicast communication.

## DESCRIPTION
UDP transport can only be used with the ZMQ_RADIO and ZMQ_DISH socket types.

## ADDRESSING
A 0MQ endpoint is a string consisting of a transport:// followed by an address. The transport specifies the underlying protocol to use. The address specifies the transport-specific address to connect to.

For the UDP transport, the transport is udp. The meaning of the address part is defined below.

Binding a socket

```
With 'udp' we can only bind the 'ZMQ_DISH' socket type.
When binding a socket using _zmq_bind()_ with the 'udp'
transport the 'endpoint' shall be interpreted as an 'interface' followed by a
colon and the UDP port number to use.
An 'interface' may be specified by either of the following:
* The wild-card `*`, meaning all available interfaces.
* The name of the network interface (i.e. eth0, lo, wlan0 etc...)
* The primary address assigned to the interface, in its numeric representation.
* Multicast address in its numeric representation the socket should join.
The UDP port number may be specified a numeric value, usually above
1024 on POSIX systems.
Connecting a socket
```

With udp we can only connect the ZMQ_RADIO socket type. When connecting a socket to a peer address using zmq_connect() with the udp transport, the endpoint shall be interpreted as a peer address followed by a colon and the UDP port number to use.

A peer address may be specified by either of the following:

•The IPv4 or IPv6 address of the peer, in its numeric representation or using its hostname.

•Multicast address in its numeric representation.

## EXAMPLES
Binding a socket.

```
//  Unicast - UDP port 5555 on all available interfaces
rc = zmq_bind(dish, "udp://*:5555");
assert (rc == 0);
//  Unicast - UDP port 5555 on the local loop-back interface
rc = zmq_bind(dish, "udp://127.0.0.1:5555");
assert (rc == 0);
//  Unicast - UDP port 5555 on interface eth1
rc = zmq_bind(dish, "udp://eth1:5555");
assert (rc == 0);
//  Multicast - UDP port 5555 on a Multicast address
rc = zmq_bind(dish, "udp://239.0.0.1:5555");
assert (rc == 0);
//  Same as above but joining only on interface eth0
rc = zmq_bind(dish, "udp://eth0;239.0.0.1:5555");
assert (rc == 0);
//  Same as above using IPv6 multicast
rc = zmq_bind(dish, "udp://eth0;[ff02::1]:5555");
assert (rc == 0);
```

Connecting a socket.

```
//  Connecting using an Unicast IP address
rc = zmq_connect(radio, "udp://192.168.1.1:5555");
assert (rc == 0);
//  Connecting using a Multicast address
rc = zmq_connect(socket, "udp://239.0.0.1:5555);
assert (rc == 0);
//  Connecting using a Multicast address using local interface wlan0
rc = zmq_connect(socket, "udp://wlan0;239.0.0.1:5555);
assert (rc == 0);
//  Connecting to IPv6 multicast
rc = zmq_connect(socket, "udp://[ff02::1]:5555);
assert (rc == 0);
```

## SEE ALSO
zmq_connect(3) zmq_setsockopt(3) zmq_tcp(7) zmq_ipc(7) zmq_inproc(7) zmq_vmci(7) zmq(7)

## AUTHORS
This page was written by the 0MQ community. To make a change please read the 0MQ Contribution Policy at http://www.zeromq.org/docs:contributing.


title: zmq_vmci(7)

text:
# zmq_vmci(7)

## NAME
zmq_vmci - 0MQ transport over virtual machine communicatios interface (VMCI) sockets

## SYNOPSIS
The VMCI transport passes messages between VMware virtual machines running on the same host, between virtual machine and the host and within virtual machines (inter-process transport like ipc).

Note Communication between a virtual machine and the host is not supported on Mac OS X 10.9 and above.

## ADDRESSING
A 0MQ endpoint is a string consisting of a transport:// followed by an address. The transport specifies the underlying protocol to use. The address specifies the transport-specific address to connect to.

For the VMCI transport, the transport is vmci, and the meaning of the address part is defined below.

### Binding a socket
When binding a socket to a local address using zmq_bind() with the vmci transport, the endpoint shall be interpreted as an interface followed by a colon and the TCP port number to use.

An interface may be specified by either of the following:

•The wild-card *, meaning all available interfaces.

•An integer returned by VMCISock_GetLocalCID or @ (ZeroMQ will call VMCISock_GetLocalCID internally).

The port may be specified by:

•A numeric value, usually above 1024 on POSIX systems.

•The wild-card *, meaning a system-assigned ephemeral port.

### Unbinding wild-card address from a socket
When wild-card * endpoint was used in zmq_bind(), the caller should use real endpoint obtained from the ZMQ_LAST_ENDPOINT socket option to unbind this endpoint from a socket using zmq_unbind().

### Connecting a socket
When connecting a socket to a peer address using zmq_connect() with the vmci transport, the endpoint shall be interpreted as a peer address followed by a colon and the port number to use.

A peer address must be a CID of the peer.

## EXAMPLES
Assigning a local address to a socket.

```
//  VMCI port 5555 on all available interfaces
rc = zmq_bind(socket, "vmci://*:5555");
assert (rc == 0);
//  VMCI port 5555 on the local loop-back interface on all platforms
cid = VMCISock_GetLocalCID();
sprintf(endpoint, "vmci://%d:5555", cid);
rc = zmq_bind(socket, endpoint);
assert (rc == 0);
```

Connecting a socket.

```
//  Connecting using a CID
sprintf(endpoint, "vmci://%d:5555", cid);
rc = zmq_connect(socket, endpoint);
assert (rc == 0);
```

## SEE ALSO
zmq_bind(3) zmq_connect(3) zmq_inproc(7) zmq_tcp(7) zmq_pgm(7) zmq_vmci(7) zmq_getsockopt(3) zmq(7)

## AUTHORS
This page was written by the 0MQ community. To make a change please read the 0MQ Contribution Policy at http://www.zeromq.org/docs:contributing.


qos

package: linux-atm

title: qos(7)

summary: Quality of Service specification

text:
# qos(7)

## NAME
qos - Quality of Service specification

## DESCRIPTION
The text2qos and qos2text functions use the format described in this man page. Because all standard ATM tools on Linux use those functions to convert to or from the textual representation of QOS specifications, they expect them in the same format too.

The most fundamental parameters are the traffic class and the AAL (ATM Adaption Layer) type. If the connection is bi-directional, both directions have the same traffic class and the same AAL type. The traffic class and the AAL type are the first elements (in any order) in a QOS specification. The traffic class is the only required element. If the AAL type is omitted, the application will provide a default value. The following traffic classes are recognized:

ubr

Unassigned Bit Rate

cbr

Constant Bit Rate

abr

Available Bit Rate

The following AAL types are recognized:

aal0

("raw ATM")

aal5

If both, the traffic class and the AAL type are specified, they are separated by a comma.

If more parameters are supplied, the traffic class and AAL type must be followed by a colon. Traffic parameters can be specified independently for the transmit and the receive direction. Their parameter lists are prefixed with tx: and rx:, respectively. If both parameter lists are present, the tx: list must precede the rx: list. If a parameter is equal for both directions, it can be placed in a common parameter list (without prefix). The general format is as follows:

class_and_aal:common_list,tx:list,rx:list

Each list consists of elements specifying a parameter. Elements can appear in any order and they are separated with commas. The following elements are recognized:

pcr=rate

is a synonym for max_pcr=rate

max_pcr=rate

The upper limit for the peak cell rate to assign. If omitted, any rate up to link speed may be chosen.

min_pcr=rate

The lower limit for the peak cell rate to assign. If omitted, any rate above zero can be chosen.

sdu=size

is a synonym for max_sdu=size

max_sdu=size

The size of the largest packet that may be sent or received. If omitted, a context-dependent default value is used.

Values are specified as follows:

rate

The (decimal) rate, optionally followed by a unit. The unit may be prefixed with one of the multipliers k, M, or G, meaning 1'000, 1'000'000, or 1'000'000'000, respectively. The units cps (cells per second) and bps (bits per second) are recognized. If multiplier and unit are omitted, cells per second are assumed. Note that the rate is always converted to cells per second, so rounding errors may occur when specifying the rate in bits per second. Rates measured in bits per second are considered to be user data rates, i.e. one cell corresponds to 384 bits. The rate can be a fractional value, e.g. 1.3Mbps. It is an error to specify only a multiplier without a unit. Link speed can be indicated by using the keyword max as the rate.

size

The (decimal) number of bytes.

The tx: or rx: lists may also just contain the single element none, which indicates that the corresponding direction is not used. It is an error to specify none for both direction.

Note that commas must never follow colons or other commas. Also, whitespace is not allowed inside a QOS specification. QOS specifications are case-insensitive.

## EXAMPLES
Each of the following lines contains a valid QOS specification:

```
  ubr

  ubr:pcr=100kbps

  cbr,aal0:pcr=64kbps

  CBR:max_pcr=11Mbps,min_pcr=10mbps,sdu=8192

  aal5,ubr:tx:none

  cbr:tx:pcr=30000,rx:none
```

The following specificiations are equivalent:

```
  CBR,AAL5:PCR=48Mbps

  cbr,aal5:max_pcr=125000

  cbr,aal5:tx:pcr=125kcps,rx:pcr=125kcps
```

## AUTHOR
Werner Almesberger, EPFL LRC/ICA <werner.almesberger@epfl.ch>


sap

title: sap(7)

summary: Service Access Point specification

text:
# sap(7)

## NAME
sap - Service Access Point specification

## DESCRIPTION
The text2sap and sap2text functions use the format described in this man page. Because all standard ATM tools on Linux use those functions to convert to or from the textual representation of SAP specifications, they expect them in the same format too.

The SAP is divided into two parts: the broadband high layer information (BHLI) and the broadband low layer information (BLLI). A SAP can contain one, both, or none of them. In the latter case, the SAP is usually considered as a wildcard SAP, i.e. a SAP that is compatible with any other SAP.

Each part begins with its name (bhli or blli), followed by a colon and a (non-empty) list of attributes, which are of the form attribute=value. Some attributes have sub-attributes, which follow them. Everything that isn't separated by a colon or an equal sign is separated by a comma.

Values which are a number of bytes are specified as the corresponding sequence of pairs of hex digits. The sequence can be optionally prefixed with 0x. Values with are integers in a given range can be specified in decimal (no prefix), octal (0 prefix), and hexadecimal (0x prefix).

The following, mutually exclusive attributes are allowed in the bhli part (see the corresponding ATM Forum and ITU documents for the semantics):

iso=1-8 bytes

ISO

user=1-8 bytes

User-specific

hlp=4 bytes

High layer profile. Note that this attribute only exists on UNI 3.0. text2sap only recognizes it if your system is configured to accept UNI 3.0 message formats.

oui=3 bytes,id=4 bytes

Vendor-specific application identifier

The structure of the bhli part is more complex. It distinguishes three layers, l1, l2, and l3, of which the first one is presently unsupported. For layer two, the following (mutually exclusive) possibilities exist:

l2=iso1745

Basic mode ISO 1745

l2=q291

ITU-T Q.291 (Rec. I.441)

l2=lapb

Extended LAPB, half-duplex (Rec. T.71)

l2=iso8802

LAN LLC (ISO/IEC 8802/2)

l2=x75

ITU-T X.75, SLP

l2=x25_ll ...

ITU-T X.25, link layer. This attribute and the following attributes through l2=iso7776 can optionally be followed by one or more of the following sub-attributes: mode=mode (mode of operation, either norm or ext), and window=window size (window size in k, 1-127).

l2=x25_ml ...

ITU-T X.25, multilink

l2=hdlc_arm ...

HDLC ARM (ISO/IEC 4335)

l2=hdlc_nrm ...

HDLC NRM (ISO/IEC 4335)

l2=hdlc_abm ...

HDLC ABM (ISO/IEC 4335)

l2=q992 ...

ITU-T Q.922

l2=iso7776 ...

ISO 7776 DTE-DTE

l2=user,info=information

User-specified. information is an integer in the range 0 to 255.

For layer three, the following (again, mutually exclusive) possibilities exist:

l3=iso8473

ITU-T X.233 | ISO/IEC 8473

l3=t70

ITU-T T.70 minimum network layer

l3=h321

ITU-T Recommendation H.321

l3=x25 ...

ITU-T X.25, packet layer. This attribute and the following attributes through l3=x223 can optionally be followed by one or more of the following sub-attributes: mode=mode (see above), size=default packet size (4-12, corresponding to 16-4096), window=window size (see above).

l3=iso8208 ...

ISO/IEC 8208

l3=x223 ...

ITU-T X.223 | ISO/IEC 8878

l3=tr9577,ipi=identifier ...

ISO/IEC TR 9577. identifier is the initial protocol identifier in the range 0-255. For SNAP (0x80), the keyword snap can be used, and the following sub-attributes have to be specified: oui=3 bytes, and pid=2 bytes.

l2=user,info=information

User-specified, see above.

l3=h310 ...

ITU-T Recommendation H.310. The sub-attribute term=type (terminal type, rx, tx, or rxtx) is recognized. If present, it enables the two additional sub-attributes fw_mpx=capability (forward multiplexing capability, ts, ts_fec, ps, ps_fec, or h221) and bw_mpx=capability. Both are optional.

Note that commas must never follow colons or other commas. Also, whitespace is not allowed inside a SAP specification. SAP specifications are case-insensitive. On input, items must be written in exactly the order used in this document.

## EXAMPLES
blli:l2=iso8802

Classical IP over ATM (RFC1577)

bhli:oui=0x0060D7,id=0x01000001,blli:l2=iso8802

Arequipa (RFC2170)

blli:l3=tr9577,ipi=snap,oui=0x00A03E,pid=0x0002

LAN Emulation

## AUTHOR
Werner Almesberger, EPFL LRC <werner.almesberger@lrc.di.epfl.ch>


lizardfs

package: lizardfs-client

title: lizardfs(7)

text:
# lizardfs(7)

## NAME
lizardfs, moosefs, mfs - a networking, distributed, highly available file system

## DESCRIPTION
LizardFS is a networking, highly available, distributed file system. It spreads data over several physical localisations (servers), which are visible to a user as one resource. For standard file operations LizardFS acts as other Unix-alike file systems. It has hierarchical structure (directory tree), stores files' attributes (permissions, last access and modification times) as well as makes it possible to create special files (block and character devices, pipes and sockets), symbolic links (file names pointing to another files accessible locally, not necessarily on LizardFS) and hard links (different names of files which refer to the same data on LizardFS). Access to the file system can be limited basing on IP address and/or password.

Distinctive features of LizardFS are:

•higher reliability (data can be stored in several copies on separate computers)

•dynamically expanding disk space by attaching new computers/disks

•possibility of storing deleted files for a defined period of time ("trash bin" service on a file system level)

•possibility of creating snapshot of a file, which means coherent copy of them whole file, even while the file is being written.

## ARCHITECTURE
LizardFS installation consists of five types of machines:

•master metadata server (or ‘the master’) a managing server - single computer managing the whole filesystem, storing metadata for every file (information on size, attributes and file localisation(s), including all information about non-regular files, i.e. directories, sockets, pipes and devices.

•metadata server shadows (or ‘the shadow’) - almost identical to the master, there can be any number of those, they work as master metadata server backup and they are ready for immediate deployment as new master in case of current master failure.

•data servers (any number of commodity servers storing files data and replicating it among themselves (if a certain file is supposed to exist in more than one copy).

•metadata backup servers - any number of servers, all of which store metadata changelogs and periodically downloading base metadata file; it’s easy to run mfsmaster process on such machine when primary master stops working.

•client computers referring to LizardFS stored files - any number of machines with working mfsmount process that communicates with the managing server to receive and modify file information and with chunkservers to exchange actual file data.

Metadata is stored in memory of the managing server and simultaneously is being saved on disk (as a periodically updated binary file and immediately updated incremental logs). The main binary file as well as the logs are replicated to metaloggers (if present).

File data is divided to fragments (chunks) of maximum size 64MB each which are stored as files on selected disks on data servers (chunkservers). Each chunk is saved on different computers in a number of copies equal to a "goal" for the given file.

## REPORTING BUGS
Report bugs to <contact@lizardfs.org>.

## COPYRIGHT
Copyright 2008-2009 Gemius SA, 2013-2019 Skytechnology sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

LizardFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.

## SEE ALSO
mfschunkserver(8), mfsmaster(8), mfsmetalogger(8), mfsmount(1), mfstools(1), lizardfs-admin(8)


package: lizardfs-master

title: lizardfs(7)

summary: a networking, distributed, highly available file system