|
|
Index: Home | What Is Izumi | Misc Links | Random Thoughts | Too Much To Read | The Rant Vault | Quotes Dev: Projects | Ideas For Dev | Nerdkill | Rig | Hint
$Id: SneII.izu,v 1.1 2005/11/05 21:55:58 ralf Exp $
20050122 Warning: This project is indefinitely put on hold.
20050225 Update: This is a utility library. It only advances when some other project needs this library. Right now I am working on some other projects that are using or may use this. So this will continue, later.
SNE is a rather simple library which purpose is to provide an easy way to build applications that need to exchange network information.
The library does not intend to be a comprehensive network library. Using network sockets under .Net is relatively easy -- most of the work is done by classes such as TcpClient and TcpListenner. Yet adding network-based interaction in an application requires a non-minimal amount of work which turns out to be pretty much generic. SNE tries to fill this gap by providing a simple skeletton on which network interaction can be based.
The keyword is "simple" here.
As such it defines a network-based application as two entities, the server and the clients. A server waits for TCP connections on a given port/address and serves services. Clients connect to a given port, address and service name. One the connection is established, server and clients exchange binary packets. The library does not impose any behavior or control on the nature of the protocol exchange between a client and a server. It is up to the library users to define their own protocol.
The notion of "services" has been introduced in an effort to further simplify usage implementation. Alternate names describing the concept would be "channels" or "protocols". For example a mail server could offer three services: one to retrieve the list of users, one to retrieve the list of folders from a given user and eventually one to retrieve the mail for a given user. The same mail server implementation could just decide to use only one service and move the distinction at the level of their own private protocol.
Implementation-wise, what is needed?
Finally note that the SNE 2 library is been implemented on two different platforms: Python and .Net Compact Framework 1.1.
.Net 2.0 is too young at this time to be actually deployed. Usage of the .Net CF allows the library to be used on Pocket PC applications at the cost of a limited API for socket programming.
20041120
To be done (by decreasing priority):
2004MMDD [1.N] Section: Desc
Finished (by decreasing date):
2004MMDD [1.N] Section: Desc
(Notes are given in chronological order.)
An overview of SNE:
There's one Server and multiple Clients connect to that server on a given port and address.
The server provides multiple services. Each service has a different name. A client connects to one service on one server.
On the server side, a service is matched by a RServiceConnection class. That is when the server is created, the host defines each service by providing a name and a class that will match incoming connections. When a client connects to a service, the server instantiate one instance of the RServiceConnection class and provides it one user parameter.
RServiceConnection derives from RConnection which provide base attributes:
The client and the server exchange RPackets, a packed array of bytes with a given size. SNE does not provide nor enforce any semantics for the packet itself, it is purely service dependant.
A client works differently. It instantiates a RClientConnection and connects to a server on a given port, address and service name. Once the connection is established, the client can use Send to send a packet and can use Receive the get a packet. A client can use three patterns:
The exchange protocol between the server and the client is very basic. When a client connects, it first sends two strings of fixed length:
After that the exchange between the client and the server is based on requests and responses. A request has a string header in the form:
"x:data\n"where "x" is a letter naming the request and data is a parameter for that request. The line ends with a '\n' character.
There's an arbitrary limit of 1024 characters in the request line.
Once a request is sent by, the receiver replies with a response code. This status code is encoded as a string in the form:
"r:NNN\n"where "r" stands for "response" and NNN are 3 digits forming a number similar to the HTTP response codes. Typical examples are 200 (OK), 400 (Bad request), 404 (Not found), etc.
So after the signature has been accepted, the client must send its version number:
"v:10\n"which stands for version "1.0".
The server will reply with either:
If the server replied 200, it will consequently accept incoming packets.
If not, it will close the connection.
101 is for future extension and may result in protocol negotiation.
101 is not currently supported.
After that the client specifies the service name:
"s:<service name>\n"
The server replies to the service name request using on of the following responde codes:
If the server replied 200, it will consequently accept incoming packets. If not, it will close the connection.
The exchange of a packet is quite straightforward.
The sender sends the packer header as a string
"p:bNNN\n"where NNN is the size of the packets to follow in bytes. Then the bytes are send as-is.
There are currently no flags, no CRC, no transmit window and no packet index.
It is expected that in the future the packet exchange may be expanded with such features. Typically CRC and re-transmit would be nice. To do this, the packet header may look like this:
"p:bNNN:cNNN:iNNN".
Each flag is composed of a colon separator and a letter. The number being is the decimal value for the flag (it may be more compact to transmit the CRC as hexa, yet more generic to transmit all values the same way.) The index will be incremented for each packet and can be used to retransmit the same packet, with the same index.
Note that since SNE solely operates on TCP connected streams, error detection and retransmit is already handled by TCP and it is thus not expected that an extension to the packet header actually be that useful.
Whenever a sender sends a packet, the receiver replies with a response code:
Error 400 has a loose meaning here. Since of the TCP nature of the connection, it is not expected that the packet was not correctly received unless the receiver is in a bad shape. It is up to the user of the protocol to decide what to do if this situation arises.
Note that the protocol does not offer compression yet. It may be added later as a flag:
"p:bNNN:zNNN"where "b" indicates the compressed size and "z" the uncompressed size, as well as the compression method (each one will use a different letter, "z" meaning zlib). CRC, if any, would be added on the compressed data.
I need a Python implementation to run it under Linux, instead of a Mono implementation. The footprint of Mono is still too big. That and Python is perfectly suited for the task.
An "alternative" implementation would be to simply rely on HTTP for the transport and the wire protocol. The benefit is obvious: passing thru firewalls is a lot easier.
Implementation wise, System.Net.HttpWebRequest is available in .Net CF 1.1. The .Net Framework does not seem to have an HTTP server just as-is. The only think I see for the server part is HttpServerChannel in System.Runtime.Remoting, which is not available on .Net CF 1.1 anyway. Well since CF doesn't have remoting, I wasn't really expecting an HTTP-server-in-one-class implementation to fall of the sky just like that :-)
Now, what does it take to simply "mimic" an HTTP protocol on the wire? Like a very basic server and client that does only the basic part HTTP 1.0? Just enough to go thru proxies and firewalls.
Obviously still a lot more than the protocol shown above.
|
|
This work is licensed by Raphaël Moll under a Creative Commons License.
|
|
| Color Theme: | Gray | Blue | Black | Sand | Khaki | Egg | None |
|
|
|
|