PS3 PS3 net servers

[jcorrea]

Alternatively you may consider using a JNI (Java Native Interface) wrapper around existing C/C++ implementations compiled as a shared library. It could be quicker to do than a java rewrite, it would ensure specs compatibility & depending on the situation, you may even be able to avoid implementing custom serialization as a bonus. It could also make future updates/fixes in the C/C++ code easier to deploy project wide.

Taken to the extreme (you should not need that here), JNI usage can even support the introduction of cpp coding into java in the same way as we can use assembly directly in C code.
Check this app out for instance:
https://github.com/bytedeco/javacpp

Sorry, but I don't intend to use JNI. It's far away easier to port the code to JAVA than write the JNI interface. I would have to deal with the original C/C++ code to add the JNI specs and I really don't want to do that.

Edit.: I checked the javacpp project, but it doesn't define how I need to deal with compiler directives, and as I don't really know how the javac interpret that at compiler level, I prefer to avoid that than have to discover how to do it when necessary.

Yes, it is the same.

AbstractFile class is a wrapper of the file functions.

You could create your own wrapper or use the functions directly.

The wrapper probably was created to make a standard code, and handle easier the port to different environments (Windows, linux, etc.)

Understood, thank you.

 

[bguerville]

Sorry, but I don't intend to use JNI. It's far away easier to port the code to JAVA than write the JNI interface. I would have to deal with the original C/C++ code to add the JNI specs and I really don't want to do that.

Edit.: I checked the javacpp project, but it doesn't define how I need to deal with compiler directives, and as I don't really know how the javac interpret that at compiler level, I prefer to avoid that than have to discover how to do it when necessary.

Np.
I suggested it because the ps3netsrv implementations to turn into a library are fairly simple & the project quite small so writing a wrapper shouldn't be very difficult. But you may prefer to rewrite the whole thing.
As to javacpp, I only mentioned it because I thought it was interesting to explore, not particularly so you would use it for this project..

 

[jcorrea]

Np.
I suggested it because the ps3netsrv implementations to turn into a library are fairly simple & the project quite small so writing a wrapper shouldn't be very difficult. But you may prefer to rewrite the whole thing.
As to javacpp, I only mentioned it because I thought it was interesting to explore, not particularly so you would use it for this project..

I understood what you suggested, but I don't intend to change the original ps3netsrv source to add the JNI interface, because I barely know how to change that and I don't know anything about C/C++ to deal with the problems that may occur. And, it's easy to write code using Java: there is only two "core" commands left to implement :

switch (ctx.getCommandData().getOpCode()) {
    case NETISO_CMD_OPEN_DIR:
        cmd = new OpenDirCommand(ctx);
        break;
    case NETISO_CMD_READ_DIR:
        cmd = new ReadDirCommand(ctx);
        break;
    case NETISO_CMD_STAT_FILE:
        cmd = new StatFileCommand(ctx);
        break;
    case NETISO_CMD_OPEN_FILE:
        cmd = new OpenFileCommand(ctx);
        break;
    case NETISO_CMD_READ_FILE:
        //handleReadFile(ctx);
        break;
    case NETISO_CMD_READ_FILE_CRITICAL:
        //handleReadFileCritical(ctx);
        break;
    default:
        throw new Exception("Unknown command");
}

 

[aldostools]

I understood what you suggested, but I don't intend to change the original ps3netsrv source to add the JNI interface, because I barely know how to change that and I don't know anything about C/C++ to deal with the problems that may occur. And, it's easy to write code using Java: there is only two "core" commands left to implement :

switch (ctx.getCommandData().getOpCode()) {
    case NETISO_CMD_OPEN_DIR:
        cmd = new OpenDirCommand(ctx);
        break;
    case NETISO_CMD_READ_DIR:
        cmd = new ReadDirCommand(ctx);
        break;
    case NETISO_CMD_STAT_FILE:
        cmd = new StatFileCommand(ctx);
        break;
    case NETISO_CMD_OPEN_FILE:
        cmd = new OpenFileCommand(ctx);
        break;
    case NETISO_CMD_READ_FILE:
        //handleReadFile(ctx);
        break;
    case NETISO_CMD_READ_FILE_CRITICAL:
        //handleReadFileCritical(ctx);
        break;
    default:
        throw new Exception("Unknown command");
}

NETISO_CMD_READ_FILE is not a core function. It is used mainly for file copy from ps3netsrv.

The 2 missing core opcodes should be:
NETISO_CMD_READ_FILE_CRITICAL // process BD & DVD ISO
NETISO_CMD_READ_CD_2048_CRITICAL // process CD ISO

 

[jcorrea]

It's alive \o/.

The ReadFileCriticalCommand was the most easy to write:

public void executeTask() throws Exception {
    byte[] result = new byte[numBytes];
    RandomAccessFile file = ctx.getReadOnlyFile();
    file.seek(offset);
    file.read(result);
    ctx.getOutputStream().write(result);
}

I got it working for PS3 isos. But there is some issues I need to check and, I also need to improve a lot the Android UI.

Edit.: nvm, I found the issue: I was creating a new instance of RandomAccessFile every ctx.getReadOnlyFile call, I already fixed it and it's working nicely

And also, I still need to implement NETISO_CMD_READ_CD_2048_CRITICAL.

 

[bucanero]

It's alive \o/.

I got it working for PS3 isos. But there is some issues I need to check and, I also need to improve a lot the Android UI.

that's great news! congrats!

About the UI, since it's a server (background service) maybe you can avoid all the UI and do something like webman Mod, having a simple HTTP server listening, where you can connect your browser, use a few checkboxes to select the shared folders, and that's it.

for example, as a first approach, it could just be a webpage with a textbox and the user enters all the options as a string (just like command line)

 

[jcorrea]

that's great news! congrats!

About the UI, since it's a server (background service) maybe you can avoid all the UI and do something like webman Mod, having a simple HTTP server listening, where you can connect your browser, use a few checkboxes to select the shared folders, and that's it.

for example, as a first approach, it could just be a webpage with a textbox and the user enters all the options as a string (just like command line)

No, it's a little bit more simple. I already have an ugly Android UI, but I will improve that . I have to put some other info, like show the Android device IP and, put some more settings like "whitelist ip", "blacklist ip" and maximum connected clients (I actually just put two text edits on settings activity: "port" - type number - and "folder" - type string - but I will try to change this to let the user select the folder with the default file explorer). I also have to find a way to Android let me choose another folder on external storage than the "app data" folder.

I send you an invite to check it at the github. You can download the latest build on "Action" (look for "artifacts" - I defined an action to build a new version on every push)

 

[AlexRhine]

@jcorrea, for a UI I would suggest something simple like Blokada 5 (see attached photo).

Maybe show the local IP below the "on" button, and add a "choose folder" button at the bottom? The app is open source if you'd like to look at their UI implementation: https://github.com/blokadaorg/blokada

By the way, since you are making the app's code public, would you consider publishing it on F-Droid?

Edit: Placed picture in attachment so it wouldn't take up the entire screen when shown in post.

 

[jcorrea]

@jcorrea, for a UI I would suggest something simple like Blokada 5:

Maybe show the local IP below the "on" button, and add a "choose folder" button at the bottom? The app is open source if you'd like to look at their UI implementation: https://github.com/blokadaorg/blokada

By the way, since you are making the app's code public, would you consider publishing it on F-Droid?

Wow, blockada is nice! I'll check that and probably this will be the "face" of the app

About F-Droid, I'll check how to publish there, but I was considering something more easy, maybe playstore? ;-)

 

[AlexRhine]

About F-Droid, I'll check how to publish there, but I was considering something more easy, maybe playstore? ;-)

For F-Droid, you can open a request for packaging, and some contributors will try to help you get the app ready for inclusion: https://gitlab.com/fdroid/rfp/-/issues. They have somewhat strict guidelines for inclusion, but this app should be fine: https://f-droid.org/docs/Inclusion_Policy/?title=Inclusion_Policy.

Aiming for play store is also good since I would expect most users to not want to install an .apk from github.

 

[jcorrea]

For F-Droid, you can open a request for packaging, and some contributors will try to help you get the app ready for inclusion: https://gitlab.com/fdroid/rfp/-/issues. They have somewhat strict guidelines for inclusion, but this app should be fine: https://f-droid.org/docs/Inclusion_Policy/?title=Inclusion_Policy.

Aiming for play store is also good since I would expect most users to not want to install an .apk from github.

As I don't intend to "monetize" the app (I hate "ads", but as it's an open source project, I also don't intend to sell it), I'll check the playstore values to release it there. I don't know the NetISO protocol license (I expect it to be MIT or some other permissive license, so I can release two versions, a "free version" and a "donation version": both without any limitation and without ads). Maybe @aldostools knows the protocol license...

 

[jcorrea]

I'm writing the ReadCD2048Command, but there is some weird constants on original ps3netsrv source (process_read_cd_2048_critical_cmd):

client->ro_file->seek(offset + 24, SEEK_SET);

Why is the offset value being added to 24?

if(client->ro_file->read(buf, 2048) != 2048)

Why is the read buffer size always 2048 if the client->CD_SECTOR_SIZE is not a constant (it's being calculated at process_open_cmd).

(https://github.com/aldostools/webMA...72334a/_Projects_/ps3netsrv/src/main.cpp#L658)

nvm, I think I found the answer to 2048 value: it means it will always read to buffer in pieces of 2KB each, it's not the same as sector size
I'm still curious about 24 value...

 

[jcorrea]

Got it, PS3 / PSX are working \o/

I'll do some code cleaning and adjust the UI to let it usable (and also, fix some problems) and will release it as soon as possible. After exact 1 year of this thread opened, there is a JAVA/Android port to ps3netsrv (but with basic functionality, only ISOs are playable yet).

Maybe the OP is still interested in it, but he/she is "away" since August/2020...

 

[bguerville]

I'm writing the ReadCD2048Command, but there is some weird constants on original ps3netsrv source (process_read_cd_2048_critical_cmd):

client->ro_file->seek(offset + 24, SEEK_SET);

Why is the offset value being added to 24?

if(client->ro_file->read(buf, 2048) != 2048)

Why is the read buffer size always 2048 if the client->CD_SECTOR_SIZE is not a constant (it's being calculated at process_open_cmd).

(https://github.com/aldostools/webMA...72334a/_Projects_/ps3netsrv/src/main.cpp#L658)

nvm, I think I found the answer to 2048 value: it means it will always read to buffer in pieces of 2KB each, it's not the same as sector size
I'm still curious about 24 value...

Am not sure but couldn't the +24 be related to the comment in the source ?

// skip subchannel data

 

[sbp]

Well I'm sure that I'm not the only one that will easily put this to use on my old android tv box. Looking forward to a release.

Cheers to your progress with ps3netsrvr android port!

 

[aldostools]

I'm writing the ReadCD2048Command, but there is some weird constants on original ps3netsrv source (process_read_cd_2048_critical_cmd):

client->ro_file->seek(offset + 24, SEEK_SET);

Why is the offset value being added to 24?

if(client->ro_file->read(buf, 2048) != 2048)

Why is the read buffer size always 2048 if the client->CD_SECTOR_SIZE is not a constant (it's being calculated at process_open_cmd).

(https://github.com/aldostools/webMA...72334a/_Projects_/ps3netsrv/src/main.cpp#L658)

nvm, I think I found the answer to 2048 value: it means it will always read to buffer in pieces of 2KB each, it's not the same as sector size
I'm still curious about 24 value...

CD data (RAW mode) normally use mode1/2048
PSX discs use CD-ROM/XA (mode2/2352)

CD sectors have: raw data + EDC/ECC codes + subchannel data

Raw data is always 2048 bytes. The other 304 bytes are used for data correction or in some games for copy protection.

The raw data (2048 bytes) starts at offset 24 in the CD sector (2352 bytes):

12 (Sync pattern)

3 (Address)

1 (Mode)

8 (Subheader)

Some PSX iso images could have non standard sizes like 2048, 2336, 2448, etc. The normal CD sector is 2352.

For PS3 iso the sector size is 2048 bytes.

CD-ROM/XA MODE-2 defines two forms:
FORM-1: 2048 bytes of data, with error correction, for data FORM-2: 2324 bytes of data, no ecc, for audio/video

The following table shows a comparison of the structure of sectors in CD-ROM XA modes:

Format	← 2,352 byte sector structure →
CD-ROM XA Mode 2, Form 1:	12 (Sync pattern)	3 (Address)	1 (Mode)	8 (Subheader)	2,048 (Data)	4 (Error detection)	276 (Error correction)
CD-ROM XA Mode 2, Form 2:	12 (Sync pattern)	3 (Address)	1 (Mode)	8 (Subheader)	2,324 (Data)	4 (Error detection)

 

[jcorrea]

I have a weird issue when running the ps3netsrv on cellphone: it's very slow (I'm using 5ghz WIFI connection). But when using the ps3netsrv "java" on computer, everything works well...

I was trying to deal with some battery saver settings on cellphone, but it didn't helps...

Only because this "issue" I didn't realease the code yet...

 

[aldostools]

Try reducing the cache buffer.
I experienced a bad lag when I developed the ps3 server using large buffers.

Maybe it could help.

 

[jcorrea]

Try reducing the cache buffer.
I experienced a bad lag when I developed the ps3 server using large buffers.

Maybe it could help.

I tried it, but it was still slow. So I decided to try on an old Xiaomi 4X (santoni), and it works flawlessly (and it doesn't have a 5ghz wifi).

I'm thinking there is some app taking a lot of bandwich and doing some kind of concurrency with ps3netsrv...

I added the IP info to the main activity, and also add a "single file chooser" to let people select the folder (but I still needs to add a button to open the file chooser, because I added an action listener to the text edit, and it is opening the file chooser only on second click...)

If someone could try it on a 4.4 Android and could test it on there and share the "feelings about it", I would be very grateful (of course I will grant access to the github and apk to install it).

 

[sbp]

I do not have an 4.4 box, but i think my tx9pro is at 8 or so and i have a s10 box u can test but it is also on a higher versionif i recall. I cant help any with testing untill after next week but let me know if they can provide you any value for tests and I'll see what i can do.