PS3 PS3 net servers

bucanero said:
haven't reviewed the code, but yes I assume that the logic approach would be to keep a thread running in a loop, waiting for connections.
Then when a connection arrives, the server usually creates a new thread or fork process to handle that connection.
Click to expand...
I think there's room to create an Arduino build using this, but I'm not sure if it has enough resources... Anyway, I'll concentrate on Android first.
 
jcorrea said:
I checked the source at:
https://github.com/aldostools/webMAN-MOD/blob/master/include/netserver.h

Does the method "netsvrd_thread" stays in a "ethernal" loop, listening for clients?
Click to expand...

Yes. It performs a loop that exits when an external event changes the variable working to false / 0.

The loop is constantly listening the port 38008 for connections.

When a remote client (PS3 netiso plugin) requests a connection, it is accepted and a new thread is created to handle the NETISO commands of that client. Up to 3 clients (MAX_CLIENTS) can be handled concurrently.

Each thread (handleclient_net) has its own infinite loop to handle the NETISO commands. Each command is identified by an opcode (NETISO_CMD_READ_FILE_CRITICAL, NETISO_CMD_READ_CD_2048_CRITICAL, etc). The opcodes and their respective data structures are described in:
https://github.com/aldostools/webMAN-MOD/blob/master/cobra/netiso.h

A typical connection starts with the command NETISO_CMD_OPEN_FILE. It calls the function process_open_cmd where a relative path of the ISO is received (e.g. /PS3ISO/game.iso). The function translates the relative path to a full path in the local file system. Then validate that the file exists, opens the file and receive a file handle, detects the sector size (2048 by default for BD and DVD, 2352 for CDs). If the ISO is multi-part, all the parts are opened with their respective file handles. A response is returned to the client telling the total size of the ISO (or sum of sizes of the multi-parts). If the file does not exists, -1 is returned.

Once the client receives the total size of the ISO, it starts sending a series of read requests for sectors until it is disconnected:
a) NETISO_CMD_READ_FILE_CRITICAL: if the ISO is a BD or DVD calls process_read_file_critical
b) NETISO_CMD_READ_CD_2048_CRITICAL: if the ISO is CD calls process_read_cd_2048_critical_cmd
c) NETISO_CMD_READ_FILE: if the client is reading a file by offset. It calls process_read_file_cmd

process_read_file_critical receives the data offset (cmd->offset) in the ISO file to be read and the amount of data to receive (cmd->num_bytes). The function reads the file at the data offset (for the file handle currently opened) and returns the raw data read. If the amount of data is larger than the buffer size, it sends multiple chunks of data. If the ISO is multi-part, the ISO part is selected based on the requested offset and the size of the first part.


For simplicity, you could try to first implement NETISO_CMD_OPEN_DIR and NETISO_CMD_READ_DIR to test the communication and list the files in the file system, then try the ISO emulation.

I suggest to initially support only single part ISO and these opcode: NETISO_CMD_OPEN_FILE & NETISO_CMD_READ_FILE_CRITICAL, then you can incrementally add more opcodes for CD or file read and multi-part support.


 
Last edited:
Ok, I already have the "basic UI" done and working as I expected. Time to move to the next challenge: write the Cobra NetIso protocol in JAVA (or, try to import the C/C++ code to the project)... It's also saving settings (folder path and, port).
 
jcorrea said:
Ok, I already have the "basic UI" done and working as I expected. Time to move to the next challenge: write the Cobra NetIso protocol in JAVA (or, try to import the C/C++ code to the project)... It's also saving settings (folder path and, port).
Click to expand...

Just in case, if you are looking for an example on how to compile c/c++ code and include it in your Java/Android stuff, you can check this repo: https://github.com/hzy3774/AndroidUn7zip

the dev built a java wrapper around the 7zip unpacker code (c++)
 
bucanero said:
Just in case, if you are looking for an example on how to compile c/c++ code and include it in your Java/Android stuff, you can check this repo: https://github.com/hzy3774/AndroidUn7zip

the dev built a java wrapper around the 7zip unpacker code (c++)
Click to expand...
Great. Just a little question: I saw hzy3774 has included the un7zip library in the android project and, the interface he/she used has some "includes" (7zExtractor.h) that handles the methods (extractFile, extractAsset, ...) called by the API:
https://github.com/hzy3774/AndroidU...648ffb/un7zip/src/main/cpp/un7zip/un7zApi.cpp

As I don't have a library to include, because ps3netsrv is a program, should I create a main.h to define the main method? (sorry about this noob question, but I never used C/C++ for nothing since the first year of the college...)
 
Last edited:
jcorrea said:
Great. Just a little question: I saw hzy3774 has included the un7zip library in the android project and, the interface he/she used has some "includes" (7zExtractor.h) that handles the methods (extractFile, extractAsset, ...) called by the API:
https://github.com/hzy3774/AndroidU...648ffb/un7zip/src/main/cpp/un7zip/un7zApi.cpp

As I don't have a library to include, because ps3netsrv is a program, should I create a main.h to define the main method? (sorry about this noob question, but I never used C/C++ for nothing since the first year of the college...)
Click to expand...

oh I totally missed this message, sorry man!

so, my concern is that ps3netsrv is a server, so the "main" will also have some threads and will have the socket process, and I'm not sure how that would work with the Java wrapper.

I'd suggest to have the networking and threading code ported to Java, and if there's any basic function like reading ISO files and folders, that stuff you could keep it in C and use it through the wrapper.
So yes in the end the app would be an hybrid, and perhaps it will be easier for you to port everything and be done with it.

my idea:
- identify the basic I/O file handling functions that can remain in C, and write a wrapper for those
- port all the socket/networking stuff, and the threading so it's native in Java

in any case, don't take this as a proved solution, as I haven't done anything using Java/Android in ages
 
bucanero said:
oh I totally missed this message, sorry man!

so, my concern is that ps3netsrv is a server, so the "main" will also have some threads and will have the socket process, and I'm not sure how that would work with the Java wrapper.

I'd suggest to have the networking and threading code ported to Java, and if there's any basic function like reading ISO files and folders, that stuff you could keep it in C and use it through the wrapper.
So yes in the end the app would be an hybrid, and perhaps it will be easier for you to port everything and be done with it.

my idea:
- identify the basic I/O file handling functions that can remain in C, and write a wrapper for those
- port all the socket/networking stuff, and the threading so it's native in Java

in any case, don't take this as a proved solution, as I haven't done anything using Java/Android in ages
Click to expand...
I got it, the thread is already running and recieving sockets :D (in Java of course...).
 
An android port will be awesome. This will possibly give old android boxes a new purpose as servers.

I will for sure set this up once ready.
 
jcorrea said:
I got it, the thread is already running and recieving sockets :D (in Java of course...).
Click to expand...
Ok, I got a byte array from the PS3 request, but I don't know the size of the opcode to get it right (I thinks it's a 4 bytes info).... Because I got a byte array starting with 0x122A (NETISO_CMD_OPEN_DIR). Is the opcode always at the start and with 4 bytes?
 
jcorrea said:
Thanks. Yeah, I did a mistake with bits and bytes, sorry. So the commands always have 16 bytes? An opCode and 14 bytes of data?
Click to expand...

The opcode is 16bit (2 bytes).

The netiso command (request received) is always 16 bytes.
Code: 
typedef struct _netiso_cmd
{
uint16_t opcode;
uint8_t data[14];
} __attribute__((packed)) netiso_cmd;

The fields (struct) in the 14 bytes of data depends of the opcode. Each opcode has a corresponding struct.

The struct of the result also depends of the opcode.

Each netiso command received executes a subroutine where the request is processed and returns a result.
 
aldostools said:
The opcode is 16bit (2 bytes).

The netiso command (request received) is always 16 bytes.
Code: 
typedef struct _netiso_cmd
{
uint16_t opcode;
uint8_t data[14];
} __attribute__((packed)) netiso_cmd;

The fields (struct) in the 14 bytes of data depends of the opcode. Each opcode has a corresponding struct.

The struct of the result also depends of the opcode.

Each netiso command received executes a subroutine where the request is processed and returns a result.
Click to expand...
so, the PS3:
sends opCode + commands (2 + 14 = first 16 bytes)
Everything that came after this is related to some information useful inside the subroutine defined by the first 16 bytes?

I'm getting NETISO_CMD_OPEN_DIR (opCode) and "0x0001000000000000000000000000" and at the 17 byte, I have a "/" slash. I understood that the PS3 is requesting to open "/", but what is the "0x0001...." on the "14 byte" array? I tried to understand the C/C++/go code, but this goes a little bit away from what I know :(
 
jcorrea said:
so, the PS3:
sends opCode + commands (2 + 14 = first 16 bytes)
Everything that came after this is related to some information useful inside the subroutine defined by the first 16 bytes?

I'm getting NETISO_CMD_OPEN_DIR (opCode) and "0x0001000000000000000000000000" and at the 17 byte, I have a "/" slash. I understood that the PS3 is requesting to open "/", but what is the "0x0001...." on the "14 byte" array? I tried to understand the C/C++/go code, but this goes a little bit away from what I know :(
Click to expand...
I think I got it. It's dpLen atribute (the size of the string that cames at the end).
 
You must log in or register to reply here.

Similar threads

Back
Top