This idea has been on the backburner for quite awhile, but I'd like to get started working on it soon. Basically I'd like a device-independent driver interface that allows high-level drivers, such as a TCP/IP stack, or a bootloader, to enumerate and communicate over low-level device transports. I'd like to be able to load a module, whether it's ps2smap, usbpegasus, or usbcable (e.g. PL230x USB cable) and have the transport type indentified automatically to a higher layer. The high-level driver need not care really what type of transport it is if it doesn't need to, as a bootloader wouldn't really care if it's using a point-to-point link such as a usb cable. This crude diagram shows the scheme of things:
+--------+ +------------+
| TCP/IP | | bootloader |
+--------+ +------------+
| |
\ /
\_ +--------------------+
| Communications API |
+--------------------+
/ | \
+-----+ +----------+ \ +-----+
|SMAP | | IEEE1394 | | USB |
+-----+ +----------+ +-----+
\
+---------+
| Pegasus |
+---------+
I would imagine that the core driver for a device, like IEEE1394 or USB, would be responsible for device enumeration and exclusive access to the device below it. Because there's only one type of SMAP device, it would also be responsible for enumeration.
High-level drivers should be able to enumerate devices, "lock" a device for exclusive access (meaning it can be enumerated by other drivers but not accessed by them), send data to a device, and register callbacks for data received on the device. It should also be notified of other events, such as device removal, and disconnection (this would be link status for SMAP) if that info is available for that type of device.
Does anyone have more ideas or suggestions about how this should work?
Communication API
I think this is a great idea, a thing I would like to see is a way to use this communication protocol between 2 PS2's (PS2<->PS2), but I'm sure you already have that in mind, to use with games and what not. Maybe Ps2menu could support it to exchange files between 2 (or more?) PS2s.
Is any one working a IEEE1394 driver? Just wondering since you got in your diagram.
Also aint there some phpbb CODE tag for showing supreme ascii art like you made properly? Or maybe you could join the revolution of the images :)
Is any one working a IEEE1394 driver? Just wondering since you got in your diagram.
Also aint there some phpbb CODE tag for showing supreme ascii art like you made properly? Or maybe you could join the revolution of the images :)
-
nosense
I think your idea rocks. I don't know about other interfaces, but IEEE1394 would create a couple of problems with the architecture you suggest.
Consider TCP/IP. Obviously, if you're going to bother to implement it, you want to make it standard so it talks to eth1394 under linux or IP/1394 under XP out of the box - so you generally only write one end. In order to do this, the 1394 interface must implement a specific config ROM & implement certain interfaces. Similarly, if you were going to implement TCP/IP over SIO, you would probably use PPP.
Anyway, my point is that YES, an application should support an abstract enpoint. This is what's presented by the network layer. Implementing different physical layer interfaces is done by implementing a different physical layer (+ others as required). If you want to use TCP over SIO you create a PPP connection and use it. If you want to use some other protocol over SIO, you implement a different network layer.
Moral - standard 7-layer architecture is already defined & widely used. I would use the same architecture. You can't separate TCP/IP from Communications from physical layer, since TCP/IP has implications for the implementation of the other 2.
cheers
Consider TCP/IP. Obviously, if you're going to bother to implement it, you want to make it standard so it talks to eth1394 under linux or IP/1394 under XP out of the box - so you generally only write one end. In order to do this, the 1394 interface must implement a specific config ROM & implement certain interfaces. Similarly, if you were going to implement TCP/IP over SIO, you would probably use PPP.
Anyway, my point is that YES, an application should support an abstract enpoint. This is what's presented by the network layer. Implementing different physical layer interfaces is done by implementing a different physical layer (+ others as required). If you want to use TCP over SIO you create a PPP connection and use it. If you want to use some other protocol over SIO, you implement a different network layer.
Moral - standard 7-layer architecture is already defined & widely used. I would use the same architecture. You can't separate TCP/IP from Communications from physical layer, since TCP/IP has implications for the implementation of the other 2.
cheers
As an addendum to this I was thinking of writing a tunnel driver. While it isn't quite as nice as a fully feldged comms API it might at least solve the immediate issue of running point to point applications (such as ps2link) over different transport mediums.
The idea is similar to many other tunnel implementations on unix systems (and maybe windows, who knows). At the top level you provide a tunnel driver, this driver is written to know about all possible underlying transport mechanisms, i.e. IP/SMAP, USB PL cable, IEEE etc.
A application can enumerate what devices the tunnel driver supports and create one or more tunnels over that protocol. Once the tunnel is created you can just use it as a read/write pipe, possibly using a fs device (well I am trying my best to get devfs used). They would also have the concept of acting as a server or client device. The upper level application doesn't care how that link is made just that it provides a reliable point to point connection.
So in ps2link's case for example (excluding udp based puts) you would
create a tunnel server with a bound IP address and port number (although those could probably be created by the tunnel driver itself) which will wait for a connection. You would have to poll the tunnel I guess to determine connection status but there may be another way. After the tunnel has been created you just read and write data to that tunnel and things _should_ work :)
If ps2link wanted to connect over USB instead it would create a USB tunnel and communicate using the same read/write/ioctl protocol is used for the IP connection. Same with IEEE or in fact any other underlying device such as SIO or SIF data i.e. EE->IOP IPC :)
Probably the biggest pain in this would be the PC side code. One thing you could do would be to multiplex data over a single connection so many applications could all talk down a single channel, this would allow for example ps2link to create specific tunnels for udp puts and tcp data, but in the USB case just create two connections to the same tunnel and the PC side multiplexer would sort things out the other end.
Anyway just a thought.
The idea is similar to many other tunnel implementations on unix systems (and maybe windows, who knows). At the top level you provide a tunnel driver, this driver is written to know about all possible underlying transport mechanisms, i.e. IP/SMAP, USB PL cable, IEEE etc.
A application can enumerate what devices the tunnel driver supports and create one or more tunnels over that protocol. Once the tunnel is created you can just use it as a read/write pipe, possibly using a fs device (well I am trying my best to get devfs used). They would also have the concept of acting as a server or client device. The upper level application doesn't care how that link is made just that it provides a reliable point to point connection.
So in ps2link's case for example (excluding udp based puts) you would
create a tunnel server with a bound IP address and port number (although those could probably be created by the tunnel driver itself) which will wait for a connection. You would have to poll the tunnel I guess to determine connection status but there may be another way. After the tunnel has been created you just read and write data to that tunnel and things _should_ work :)
If ps2link wanted to connect over USB instead it would create a USB tunnel and communicate using the same read/write/ioctl protocol is used for the IP connection. Same with IEEE or in fact any other underlying device such as SIO or SIF data i.e. EE->IOP IPC :)
Probably the biggest pain in this would be the PC side code. One thing you could do would be to multiplex data over a single connection so many applications could all talk down a single channel, this would allow for example ps2link to create specific tunnels for udp puts and tcp data, but in the USB case just create two connections to the same tunnel and the PC side multiplexer would sort things out the other end.
Anyway just a thought.
-
nosense
what's wrong with PPP? There's loads of public code around for PPP, you only need to write IOP side since PC side is standard & best of all, there is no midification required at all to the app interface on either end. It's also more efficient that tunneling standard TCP/IP headers over a slow link. When standard methods exist and are widely implemented, I definitely think it's best to use them - unless there is explicit need to do otherwise.
Uh? PPP's main job is to tunnel TCP/IP over a slow link. What are you talking about? Furthermore, why would you try to implement PPP over USB or IEEE1394 when there are preexisting methods of getting TCP/IP (or other data) over them? Also, I'd like to see you get PPP over USB working on the PC side :).
Lemme just add the whole thing about my initial post is to reduce the level of complexity when communicating between the PS2 and PC clients. I don't want them to care exactly *how* they get across the wire, as long as they know that something is listening on the other side. I already have plans to move ps2link off of TCP/IP and just use UDP, because IMO including ps2ip as a full IP stack just to load a program is just too much overhead for a bootloader. Again, I want ps2link to be able to send over other transports, and if it's just a point-to-point connection then TCP/IP doesn't make sense there either. I want to remove layers, not pile them on :). TCP/IP is just too bulky for connecting machines that sit 6 feet apart from each other.
If you're moving to UDP, any thoughts to using the network broadcast as its address if no IP is given?
Actually, I'd like something like this for sending a command:
1) A client sends out a query packet, with its ID, to 255.255.255.255.
2) Each PS2 on the network responds by sending its ID to 255.255.255.255.
3) Client sends command packets with this ID, again to 255.255.255.255.
Request/response pairs for host: access could be done with these IDs, which could just be the MAC address or something else unique. Log text could even be extended to send both the ID and a channel ID so multiple text streams could come from one PS2. Also, the query packet could the status of the PS2 so the client could do things like run a program on the first available system on the network and other neat stuff.
Actually, I'd like something like this for sending a command:
1) A client sends out a query packet, with its ID, to 255.255.255.255.
2) Each PS2 on the network responds by sending its ID to 255.255.255.255.
3) Client sends command packets with this ID, again to 255.255.255.255.
Request/response pairs for host: access could be done with these IDs, which could just be the MAC address or something else unique. Log text could even be extended to send both the ID and a channel ID so multiple text streams could come from one PS2. Also, the query packet could the status of the PS2 so the client could do things like run a program on the first available system on the network and other neat stuff.
It would be nice to have some auto discover feature for PS2Link, there isn't a great point to having a bound IP address for PS2Link but then again what about other stuff like PS2NetFS? I am not sure whether I would want to advocate the use of broadcasts though, we are realistically trying to solve a point to point issue here, I can't imagine an immediate scenario where I would need to load-share a farm of PS2s :) If we know the MAC address of our PS2 (no doubt on the back of the NIC itself) we could just populate the ARP cache fixing a specific IP address from the client side and sending data directly over 802.3 frames, no IP involved at least on the PS2 end :P Even better if we could write 802.3 frames directly to the ethernet card on the host but that might be more of a hassle.
And slighty going off the point :P
My major worry for UDP is making sure everything works as expected. With TCP/IP, as long as your stack is reasonable, things should just work. Ok it might be slower and a resource wh0re but I am not sure how much we would gain without adding some proportion of clever code for the UDP packets which no doubt would have to be replicated on the PC side as well.
We could for example implement something like TFTP (and relegate normal host support to an optional extra) but the efficiency of TFTP is shall we say not exactly optimal, though it might be better than currently available with ps2ip. Still if we wanted a better protocol we have to a) design such a protocol (if we can't find something suitable) and b) force implentation on the client authors for PC side code. This probably won't be a major issue but it all adds extra complexity and doubt to the reliability of ps2link as a whole.
I don't want to see TCP idioms sneaking in the back door if we use UDP but I also don't want to start having to plug PC to PS2 using a cross-over cable ;)
Of course if we could abstract the communication interface we could easily test UDP to see if it was feasible, or have TCP/IP fall back or even USB and PS2Link would not need to change which as MRBrown says would be a good thing.
And slighty going off the point :P
My major worry for UDP is making sure everything works as expected. With TCP/IP, as long as your stack is reasonable, things should just work. Ok it might be slower and a resource wh0re but I am not sure how much we would gain without adding some proportion of clever code for the UDP packets which no doubt would have to be replicated on the PC side as well.
We could for example implement something like TFTP (and relegate normal host support to an optional extra) but the efficiency of TFTP is shall we say not exactly optimal, though it might be better than currently available with ps2ip. Still if we wanted a better protocol we have to a) design such a protocol (if we can't find something suitable) and b) force implentation on the client authors for PC side code. This probably won't be a major issue but it all adds extra complexity and doubt to the reliability of ps2link as a whole.
I don't want to see TCP idioms sneaking in the back door if we use UDP but I also don't want to start having to plug PC to PS2 using a cross-over cable ;)
Of course if we could abstract the communication interface we could easily test UDP to see if it was feasible, or have TCP/IP fall back or even USB and PS2Link would not need to change which as MRBrown says would be a good thing.
Its the same protocol, it just has support for a default IP of 255.255.255.255 if no other IP is specified. The exact same sequence of commands can be sent... We just gain the ability to run programs without having to pre-configure ps2link (a pain to burn a cdr each time for some of us), and the ability to make it useful to professional development by supporting multiple units on the same network.
While we're at it, having the query packet return what kind of system it is could open the door to multiple system types (PS2/PS3/GC/whatever) on the same network all using the same client and protocol. We're not going to be doing PS2 forever and it would be nice to be able to continue using some of these tools...
While we're at it, having the query packet return what kind of system it is could open the door to multiple system types (PS2/PS3/GC/whatever) on the same network all using the same client and protocol. We're not going to be doing PS2 forever and it would be nice to be able to continue using some of these tools...
-
Guest
ooPo wrote:Its the same protocol, it just has support for a default IP of 255.255.255.255 if no other IP is specified. .
It is good to try to find easier ways to configure IP. This method
might work for the lone hacker who just wants to create a solution,
but my suggestion would be to avoid putting this kind of solution
into a package that might be even lightly distributed to others.
I am speaking as a systems and network administrator of many
years, you do not want to do this! :) The troubles can be numerous
and hard to troubleshoot when things go wrong! I will be happy
to elaborate if desired. For now, I will instead offer some alternatives
to that might make quick and dirty IP configuration easier.
The first method, in use for years by SunOS for diskless client IP
configuration, is called "RARP" or "Reverse Address Resolution Protocol".
RARP has an advantage over other protocols such as BOOTP and DHCP
in that it is by far the most simplest. If you want to code RARP client
functionality into your software, you should be able to do it quickly!
RARP is a very low level protocol, same as ARP, at Layer 2 of the
protocol stack (lower than IP, and no IP addresses are involved in
communications here, except as 'data' payload in the response
packets.
It essentially works like this:
1. Client doesn't know its IP address. It sends out a MAC level broadcast
with a RARP packet that basically shouts "Hey! This is my MAC addr,
does anyone out there know my IP address??"
2. A system out in the network that is configured to run a RARP server
daemon, and has your client's host-ip/MAC address pair configured
into an "ethers" table or ARP table will see the broadcast, formulate
a response packet, and respond back to the client. The response will
be sent directly to the client via MAC address.
3. The client sees the response, snarfs the IP address out of the packet,
and configures its interface to that IP address.
Now your client has an IP address! Of course, it still doesn't know its
proper netmask, broadcast address, routers, etc... it needs to find those
out by other means, but usually what it has now is enough to meet the
minimum needs you outline. Most rarp clients assume the netmask and
broadcast address are based on full network level ip addressing (as
opposed to subnets). In other words, if the IP is a pure class C address,
the mask is /24, class B is /16, etc... And the netmasks are the last IP
addresses. If you subnet your network with a netmask diffferent from
the default, you might have difficulties, but most people at home won't
run into this problem.
Most OS's have rarpd servers (such as linux and MacOS, commercial
UNICES, etc... probably MSFT has one included, or should be easily
found on the net), so that part would not be difficult.
If you are really adventurous, you could go do bootp/dhcp route, which
will configure everything tcp/ip-wise from the getgo, but it depends on
your time involvement.
Hope this helps.
Gorim
-
Guest
Actually, TFTP would be my recommendation. Its still widely used allTyRaNiD wrote:
We could for example implement something like TFTP (and relegate normal host support to an optional extra) but the efficiency of TFTP is shall we say not exactly optimal, though it might be better than currently available with ps2ip. Still if we wanted a better protocol we have to a) design such a protocol (if we can't find something suitable) and b) force implentation on the client authors for PC side code. This probably won't be a major issue but it all adds extra complexity and doubt to the reliability of ps2link as a whole.
.
over the world for Cisco routers, (many other IT vendors' equip too),
Sun workstations use it to load their boot kernels in diskless mode. Its
probably used millions of time a day still in this world.
TFTP was designed for this purpose. While UDP by itself is not
optimal as a transport, you can put extra checksums on things
to make sure you loaded something correct. If you won't use
TCP (don't blame you), and if TFTP is no good due to UDP, then
you have to spend time rolling your own. Nothing wrong with that
as an exercise, but there are lots of TFTP client code examples out
there, and its already a standard and still quite accepted means to
do this task, and I am always a big believer in following tried and
true methods of doing things in the absence of compelling reasons
to do otherwise. Just call me a stick in the mud! :)