PK(4) Kernel Interfaces Manual PK(4)NAME
pk - packet driver
DESCRIPTION
The packet driver implements a full-duplex end-to-end flow control strategy for machine-to-machine communication. Packet driver protocol
is established by calling pkon(2) with a character device file descriptor and a desired packet size in bytes. The packet size must be a
power of 2, 32<=size<=4096. The file descriptor must represent an 8-bit data path. This is normally obtained by setting the device in
raw mode (see ioctl(2)).
The actual packet size, which may be smaller than the desired packet size, is arrived at by negotiation with the packet driver at the
remote end of the data link.
The packet driver maintains two data areas for incoming and outgoing packets. The output area is needed to implement retransmission on
errors, and arriving packets are queued in the input area. Data arriving for a file not open for reading is discarded. Initially the size
of both areas is set to two packets.
It is not necessary that reads and writes be multiples of the packet size although there is less system overhead if they are. Read opera-
tions return the maximum amount of data available from the input area up to the number of bytes specified in the system call. The buffer
sizes in write operations are not normally transmitted across the link. However, writes of zero length are treated specially and are
reflected at the remote end as a zero-length read. This facilitates marking the serial byte stream, usually for delimiting files.
When one side of a packet driver link is shut down by close(2)or pkoff (see pkon(2)), read(2) on the other side will return 0, and write on
the other side will raise a SIGPIPE signal.
SEE ALSO pkon(2), pkopen(3)
local PK(4)
Check Out this Related Man Page
PKOPEN(3) Library Functions Manual PKOPEN(3)NAME
pkopen, pkclose, pkread, pkwrite, pkfail - packet driver simulator
SYNOPSIS
char *pkopen(fd)
pkclose(ptr)
char *ptr;
pkread(ptr, buffer, count)
char *ptr, *buffer;
pkwrite(ptr, buffer, count)
char *ptr, *buffer;
pkfail()
DESCRIPTION
These routines are a user-level implementation of the full-duplex end-to-end communication protocol described in pk(4). If fd is a file
descriptor open for reading and writing, pkopen carries out the initial synchronization and returns an identifying pointer. The pointer is
used as the first parameter to pkread, pkwrite, and pkclose.
Pkread, pkwrite and pkclose behave analogously to read, write and close(2). However, a write of zero bytes is meaningful and will produce
a corresponding read of zero bytes.
SEE ALSO pk(4), pkon(2)DIAGNOSTICS
Pkfail is called upon persistent breakdown of communication. Pkfail must be supplied by the user.
Pkopen returns a null (0) pointer if packet protocol can not be established.
Pkread returns -1 on end of file, 0 in correspondence with a 0-length write.
BUGS
This simulation of pk(4) leaves something to be desired in needing special read and write routines, and in not being inheritable across
calls of exec(2). Its prime use is on systems that lack pk.
These functions use alarm(2); simultaneous use of alarm for other puposes may cause trouble.
deprecated PKOPEN(3)
How can I be assured that my machine is secure against buffer overflows, remote packet sniffing, and brute force attacks?
Why does the internet have to be so scary? Why can't we all just get along? (2 Replies)
Is there any importance of LS length in DB exchange packet of OSPF protocol as its should be always be 20 bytes. Is this length to be ignored (2 Replies)
We're running Solaris 7 on FDDI n/w on an E6500 host and wish to use MTU (packet size) > 1500, more like 3072 bytes to begin with and possibly up to 4096 bytes.
Linux has /etc/network/interfaces. Does ANYONE remember the equivalent in Unix? When I do ifconfig eth0 mtu 4000, I get the error... (0 Replies)