Does anybody know if the player-executable on an MK1 also listens on TCP/UDP port 8300 for emplode connectivity?

Frank van Gestel

Frank, are you busy with a PPP serial link by any chance?

One of the few remaining Mk1 owners... #00015

btw: anybody successfully got a ppp-lin over usb ?

bobo

Frank, are you busy with a PPP serial link by any chance?

Kinda, I finally found a way to talk to the empeg over USB on win32 using the empegcar.sys driver. I know it should be possible to start PPP this way, but then I would have to write a virtual dialup-adapter or at least a virtual comm-port, which seems out of reach for me...
I'm going to take a simpler approach by list for TCP/UDP ports on the win32 machine which get forwarded to the empeg. I currently have a program which listens on port 80 on the windows machine. when I log in to the empeg over serial and give command :

# cat /dev/usb

and then start a webbrowser to point to http://localhost, I can see the request from the webbrowser scroll by in hyperterm. My next step is to write a daemon for the empeg with some simple multiplexing protocol. The main idae is to run a small program on the win32 side with a simple dialog to make mappings from TCP/UDP on the win32 machine to the empeg :

win32:TCP/1080 -> empeg:TCP/80	//displayserver

win32:TCP/21 -> empeg:TCP/21	//ftp passive mode

win32:TCP/8300 -> empeg:TCP/8300 //emplode

win32:UDP/8300 -> empeg:UDP/8300 //emplode

The only problem is that the player app is constantly using the USB device-file, which is why I asked if the player app on the MK1 also uses TCP/UDP. If this is the case, you could turn off USB in the player app and connect by specifying 127.0.0.1 in emplode...

Frank van Gestel

Does anybody know if the player-executable on an MK1 also listens on TCP/UDP port 8300 for emplode connectivity?

Only Mk2 players do that, sorry.

Peter

A kind of proxy service for the empeg - excellent idea.

Unforch - I can't tell you what you wanted to know. I suspect Mike or Roger are the ones (and they must be busy with 1.1 )

One of the few remaining Mk1 owners... #00015

Sorry to hear that (for MK1 users). I guess this would mean that the player app would have to shutdown prior to setting up a USB-link or perhaps restart with USB disabled.
I allready tried to replace /dev/usb with a file or named pipe, unfortunately this will make the player-app wait endlessly at initialisation time. there's probably some ioctl which doesn't get honored.

Frank van Gestel

Are you trying to use the system device following an open?

Are you modifying the system USB device?

What happens if you try an open on the USB device if it has already been opened? Is it exclusive?

One of the few remaining Mk1 owners... #00015

Are you trying to use the system device following an open?
Are you modifying the system USB device?

At the current state I only did a cat of /dev/usb ( which is a symlink to /dev/usb0 ), to see that data was transmitted from the remote machine.

What happens if you try an open on the USB device if it has already been opened? Is it exclusive?

It's not totally exclusive I think, as a cat succeeds when the player app is running, but I guess all data sent by the client is swallowed by the player-app ( I'm not totally sure on this, will check this evening )

Frank van Gestel

It's not totally exclusive I think, as a cat succeeds when the player app is running, but I guess all data sent by the client is swallowed by
the player-app ( I'm not totally sure on this, will check this evening )

Received data on USB is randomly distributed over all readers of /dev/usb. I think the easiest solution is to restart the player-app with USB disabled using the quit option. A suitable init-script would be easy...

Frank van Gestel

This is less than good. It implies that the driver has no opening process owner identification method. Doesn't even sound as if it has a locking mechanism.

One of the few remaining Mk1 owners... #00015

This is less than good. It implies that the driver has no opening process owner identification method. Doesn't even sound as if it has a locking mechanism.

There's nothing wrong with the driver, it's just limited by design - there's normally only one reader. Unless you run something like TCP/IP over the USB link and force all readers to use it (which the player currently doesn't), there's no sensible way of handling multiple readers of what is fundamentally a single pipe.

That doesn't mean you can't hack around it, though...

Borislav

Unix generally doesn't have locking on devices. It only recently acquired proper locking on files. You can open a serial device (/dev/ttyS0, e.g.) in multiple processes. Events and data are distributed arbitrarily amongst all the processes with it open.


Roger - not necessarily speaking for empeg