1
NitroTracker Feature Requests / Re: Network ideas
« on: October 12, 2011, 11:52:37 »
Sorry, I moved it to the issue tracker as well.
- November 23, 2024, 12:16:16
- Welcome, Guest
News:
Please note: Your main modarchive.org account will not work here, you must create a forum account to post on the forums.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
NitroTracker Feature Requests / Re: Network ideas
« on: October 12, 2011, 11:28:36 »
I gave this some more thought, and came to the following solutions:
WARNING! If you prever http website standards that can be done as well, if you like to hear more of a challenge, read on.
You can resolve my link "henry00.ftpaccess.cc" I bought from dyndns.com by making a UDP connection on port 0, with the ip being that adress, it's invalid and ends up at a nameserver sending you a string with the correct ip adress.
Server:
Waits for a client to say a command.
Send directory list or if given file to client
1:/ or 1:/techo/ or 1:/techo/hardcb1.wav etc.
Server will prevent files larger then 4mb to be send to the client.
Upload file send by client
Server will download the file from the client, and puts it in a reviewable directory acccessable on a website I can create for you, to listen live and agree or disagree, change directory.
Client:
Sends directory commands to the server, and downloads directory listings or files from the server with a timeout of 10 seconds ( in the meantime the GUI is disabled, or the menu is untouchable but scrollable ).
TCP:
This task is very hard to achieve with UDP, it can be done but I'd rather see TCP in action here.
Server:
Stores 5 chat messages, each with a unique ( counting ) id.
Client:
Can send messages of maximum 200 bytes ( this includes the username ).
With 1024 bytes of memory for this task we have all the space we need. 1000 bytes are used to store 5 chat messages, and 24 bytes for internal use ( last message id etc )
Runtime:
The client connects to the server, depending on TCP ( active connection ) or UDP ( hello message ), the following system can run on UDP.
UDP:
Client sends heartbeat including the last chat message id ( number ) on which the server will check how many messages to send to the client ( each 200 bytes ). Server only sends 1 recent message until the Client keeps sending the correct value.
TCP:
Client waits for server to send a message, and downloads it. TCP will handle the secured and guaranteed delivery, but this can actually pause threads.
WARNING! If you prever http website standards that can be done as well, if you like to hear more of a challenge, read on.
You can resolve my link "henry00.ftpaccess.cc" I bought from dyndns.com by making a UDP connection on port 0, with the ip being that adress, it's invalid and ends up at a nameserver sending you a string with the correct ip adress.
If there would be a file sharing system, it would be like follows:
Server:
Waits for a client to say a command.
Send directory list or if given file to client
1:/ or 1:/techo/ or 1:/techo/hardcb1.wav etc.
Server will prevent files larger then 4mb to be send to the client.
Upload file send by client
Server will download the file from the client, and puts it in a reviewable directory acccessable on a website I can create for you, to listen live and agree or disagree, change directory.
Client:
Sends directory commands to the server, and downloads directory listings or files from the server with a timeout of 10 seconds ( in the meantime the GUI is disabled, or the menu is untouchable but scrollable ).
TCP:
This task is very hard to achieve with UDP, it can be done but I'd rather see TCP in action here.
If there would be a chat, it would be like follows:
Server:
Stores 5 chat messages, each with a unique ( counting ) id.
Client:
Can send messages of maximum 200 bytes ( this includes the username ).
With 1024 bytes of memory for this task we have all the space we need. 1000 bytes are used to store 5 chat messages, and 24 bytes for internal use ( last message id etc )
Runtime:
The client connects to the server, depending on TCP ( active connection ) or UDP ( hello message ), the following system can run on UDP.
UDP:
Client sends heartbeat including the last chat message id ( number ) on which the server will check how many messages to send to the client ( each 200 bytes ). Server only sends 1 recent message until the Client keeps sending the correct value.
TCP:
Client waits for server to send a message, and downloads it. TCP will handle the secured and guaranteed delivery, but this can actually pause threads.
3
NitroTracker Feature Requests / Network ideas
« on: October 11, 2011, 20:30:23 »
Hi my name is Henry00³ from 00Laboratories! www.00laboratories.com
I have been using Nitrotracker alot and one thing that could really dramasticly improve the program would be to have the ability of downloading / uploading -> songs / samples.
My server has 200GB ( and soon expanded to 1.5TB ) and enough upload speed to cover the small files used by Nitrotracker, and I would gladly offer the webspace for this purpose!
If it would make things simpeler I could write you a tcp/ip server to help with receiving and sending files. ( 00Laboratories = programming team, something like that is simple for me.. )
This could also result in the ability to communicate with other componists in the application, or having a dramatic multiplayer mode with a more primitive gui.
I don't know if this is too much work or too instable or too cpu intensive, but if it's possible please let me know what's possible and I will help as much as I possibly can!
(I was mainly hoping for file sharing, but the rest is fun too.)
Greets,
Henry00³ ( de Jongh )
I have been using Nitrotracker alot and one thing that could really dramasticly improve the program would be to have the ability of downloading / uploading -> songs / samples.
My server has 200GB ( and soon expanded to 1.5TB ) and enough upload speed to cover the small files used by Nitrotracker, and I would gladly offer the webspace for this purpose!
If it would make things simpeler I could write you a tcp/ip server to help with receiving and sending files. ( 00Laboratories = programming team, something like that is simple for me.. )
This could also result in the ability to communicate with other componists in the application, or having a dramatic multiplayer mode with a more primitive gui.
I don't know if this is too much work or too instable or too cpu intensive, but if it's possible please let me know what's possible and I will help as much as I possibly can!
(I was mainly hoping for file sharing, but the rest is fun too.)
Greets,
Henry00³ ( de Jongh )
Pages: [1]