After working with UDP and Revolution for just a few days I already
have a wish list.
My suggestions are not informed by Revolution heritage. I have no
idea how sockets on Revolution evolved or how long sockets have
been around in similar environments.
My suggestions ignore my (limited) experience in sockets
programming. I didn't inhibit my suggestions based on what I would
guess to be the implementation.
My suggestions are not informed by experience in using TCP with
Revolution. I have not tinkered with TCP yet (in Rev).
Of course, being new to Revolution, I may have goofed. In those
cases these comments illustrate how an experienced UDP programming
can get confused.
Summary
The primary problem is not being able to get or control some socket
info.
The notion of <socket-info> is added. It is a string of the form
"10.5.5.33:3000,10.5.5.98:3001", where each part is optional where
it is does not apply or does not matter. I make these suggestions:
1.A Callbacks for "accept datagram" include <socket-info>
2.B+ Command "open" allows <socket-info> to spec the open
3. Allow read from socket opened with "open datagram"
4. Accept allows <socket-info> to spec port & allowed datagrams
5. Function socketInfo(<anOpenSocket>) returns <socket-info>
General (TCP & UDP)
In the sockets model, every TCP connection, every received UDP
datagram, every sent UDP datagram and (often) every virtual "UDP
connection" have these four elements:
Local IP Address
Local Port
Remote IP Address
Remote Port
The values of these should be available to a script. With a couple
limitations, a script should be able to control these. There is a
tight restriction on the Local IP Address. Also, a received UDP is
a done deal; setting addresses and ports on it does not make
sense. Some of my suggestions below assume that specifying the
local IP address might be meaningful.
These values can be represented in strings. My suggestions below
refer to this recommendation for representation. I think I defined
these in a way that makes implementations of suggestions might be
backwards compatible.
I assume <address> is the dotted notation and <port> is the
positive numeral.
The <address-port> is this: [ [ <address> ] : [ <port> ] ]
Some contexts may allow either the <address> or the <port> to be
optional.
The <socket-info> is this: <address-port> [ , <address-port> ]
SUGGESTIONS
These are vaguely in order of importance. The first two are most
important.
1. Suggestion:
Messages sent because of "accept datagram socket" include the
remote port.
Problem: The message has two parameters: <address>|<connectionID>
and the datagram content. To reply the code needs both the remote
address and the remote port and the remote port is not available.
Here are three ways to handle this.
A.
Put the <socket-info> (see above) of the received UDP datagram into
a third parameter. This should be backwards compatible. It also
allows the handler to take care of multiple "accepts".
B.
Put the <port> (remote) into a third parameter. This should be
backwards compatible, too.
C.
Change the first parameter to <address-port>|<connectionID>. This
is familiar notation, but it has variant semantics; it is not a
handle to a socket. Also, this might break some existing code.
(The "accept datagram socket" should accept datagrams from any
source, unless Suggestion 4, below, is implemented.)
(This can be generalized for TCP; all references to the third
parameter in the callback would be generalized to the last
parameter.)
2. Suggestion:
Allow local specs in "open datagram socket"
Problem: Some applications and equipment accept datagrams only
from a particular port or address and port. Also, this is useful
with the next suggestion.
Here are some ways to do this.
A.
Change the syntax of "open datagram socket" to this:
open datagram socket [to] <address-port>[|<id>] \
[from <address-port>] [with message <message-name>]
This adds the "from" phrase and should be backwards compatible.
This would fail on an invalid local IP address.
B.
Change the syntax of "open datagram socket" to this:
open datagram socket [to] <socket-info>[|<id>] [with message-name]
This packs more info into the "to" phrase and should be backwards
compatible. It might also be a simpler implementation transition
than 2-A. An empty remote address could be interpreted as local
host. This fits into a general scheme of allowing socket info to
spec sockets.
(Issues concerning <id> and "with message" are independent and ignored.)
If Suggestion 3 below is not implemented, the local port specified
in "open" is allowed to be the same as a local port specified in
"accept datagram" and the other way around.
(Actually, there is nothing particular to UDP about this, this can
be generalized to include TCP.)
3. Suggestion:
Allow "read from socket" with socket opened with "open datagram socket".
Problem: There is a need to make links based on UDP. Often both
ends know (and enforce) the exact link ("UDP connection").
(It could be that this is currently present, but because of
problems for 1 and 2 above, I was not able to figure it out.)
UDP is connectionless, but one can think of a virtual link between
two ports as a "UDP connection" and a socket model can apply.
Furthermore there is no asymetry as there is in TCP. There should
be no need for "open" on one end and "accept" on the other; both
ends should be able to use "open".
There should be one callback message for each UDP datagram. Here
are some options for what the data (currently in variable it)
contains.
A.
The data is the entire datagram content; "for" and "until" are ignore.
B.
The data is read from the datagram just as a "read from socket" for
TCP would read from a connection. The end of the datagram is
handled the same as the end of a connection. (Something reasonable
should happen in both cases.)
C.
This is the same as B, except the default is A (entire datagram,
not 1 character).
If the remote is not multicast or broadcast, only datagrams from
the specified remote address and port prompt callback messages.
(It would be nice if this is filtered as low as possible in the OS
environment.) (At this time I make no comment on multicast and
broadcast.)
4. Suggestion:
Allow more specification in "accept datagram socket"
Problem: No problem really. This would be handy if #3 is not
implemented. Even if #3 is implemented, this could be part of a
generality in which every open or accept may be specified in the
most general way.
The new syntax would be this:
accept datagram connections on [port] <socket-info> \
with message <callbackMessage>
This should be backwards compatible.
If the remote address or port are specified, only datagrams from
the specified remote will prompt callbackMessage to be be sent.
(This can be generalized to include TCP.)
5. Suggestion:
Add the new function socketInfo(<anOpenSocket>)
This function returns the <socket-info> for any socket in open
sockets, otherwise "not an open socket" (or whatever the phrase
is). If the socket is a datagram accept, then the remote address
and port are blank.
The functions hostAddress() and peerAddress() are kept, but are
redundant.
Dar Scott
Dar Scott Consulting
_______________________________________________
improve-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/improve-revolution
