PPP in half duplex - PPP

This is a discussion on PPP in half duplex - PPP ; I have an application for a 'one wire' and ground PPP serial connection. This is long (2-3 mi) coax, too long for ethernet, but I can transmit megabaud serial OK thru it. Is it possible to force PPP to half ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: PPP in half duplex

  1. PPP in half duplex

    I have an application for a 'one wire' and ground PPP serial
    connection. This is long (2-3 mi) coax, too long for ethernet, but I
    can transmit megabaud serial OK thru it.

    Is it possible to force PPP to half duplex, so TX and RX can share the
    same conductor?

    I can handle the electrical side of this so the TXs go passive when
    they are not transmitting and the signals do not fight each other.

    The issues are:

    I need to disable RX interrupt from the endpoint I am transmitting, so
    I do not 'hear myself'

    That the transmitters never go active when they detect serial data on
    their RX's untill EOT

    This is a master slave setup, where only one guy will ask for data.
    The master will request a file from slave and let an already built
    protocol (PPP) do error check and retransmit frames as required.

    I want to FTP files from the slave, but I must share the same TX RX
    medium NO modems just baseband serial going two directions, one at a
    time. Half duplex.

    Thanks in advance,

    Randy Dawson

  2. Re: PPP in half duplex

    Randy Dawson writes:
    > I have an application for a 'one wire' and ground PPP serial
    > connection. This is long (2-3 mi) coax, too long for ethernet, but I
    > can transmit megabaud serial OK thru it.
    >
    > Is it possible to force PPP to half duplex, so TX and RX can share the
    > same conductor?


    In general, PPP cannot run half-duplex. This is stated right up front
    in RFC 1661:

    1. Introduction

    The Point-to-Point Protocol is designed for simple links which
    transport packets between two peers. These links provide full-duplex
    simultaneous bi-directional operation, and are assumed to deliver
    packets in order. It is intended that PPP provide a common solution
    for easy connection of a wide variety of hosts, bridges and routers
    [1].

    However, what really matters here is whether the medium *appears* to
    be full duplex to users. For instance, plain old Ethernet is actually
    half-duplex -- there's at most one transmitter at a time -- but the
    way the protocol is specified (using idle and collision detection), it
    *appears* to be full duplex to the clients because they can transmit
    at any time. Thus, PPP can run over Ethernet despite the apparent
    mismatch.

    So, if your physical layer implementation somehow allows for automatic
    turn-around, such that neither PPP peer ever has to issue 'go ahead'
    signals, and neither functions as a master or slave, then you can make
    this work.

    > I need to disable RX interrupt from the endpoint I am transmitting, so
    > I do not 'hear myself'


    Right. PPP will fall apart if that happens.

    > That the transmitters never go active when they detect serial data on
    > their RX's untill EOT


    Right. If you can emulate something like Ethernet at the physical
    layer -- check for idle, start sending, make sure you're not
    overlapping with the (or any) peer, back off in case of trouble and
    try again -- then you should be good to go.

    > This is a master slave setup, where only one guy will ask for data.
    > The master will request a file from slave and let an already built
    > protocol (PPP) do error check and retransmit frames as required.


    No. Master/slave is fine from the application layer design, but PPP
    itself requires the underlying physical connection to be peer-to-peer.

    > I want to FTP files from the slave, but I must share the same TX RX
    > medium NO modems just baseband serial going two directions, one at a
    > time. Half duplex.


    If you really want to do half-duplex (requiring some sort of polling
    and line turn-around signal), you're on your own. It might be
    possible to do this by hacking the PPP state machine and constraining
    the way the protocol is designed to work, but that's essentially
    equivalent to inventing a _new_ protocol that just happens to look a
    bit like PPP. It won't be compatible with any other implementation.

    If compatibility isn't important for some reason (some sort of 'walled
    garden'), then that might be reasonable. It might also be fairly hard
    to make reliable.

    (It might also be possible to make such a line turn-around mechanism
    simply turn the line around continuously when idle. That'd be
    sufficient, though perhaps a bit tricky to get right in the face of
    errors, and the processing overhead might be considered "high,"
    depending on the design constraints.)

    --
    James Carlson, IP Systems Group
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

+ Reply to Thread