How much code would it take...

All off topic discussions go here. Everything from the funny thing your cat did to your favorite tv shows. Non-programming computer questions are ok too.
Post Reply
User avatar
Zacariaz
Member
Member
Posts: 1069
Joined: Tue May 22, 2007 2:36 pm
Contact:

How much code would it take...

Post by Zacariaz »

The new via epia pico-itx board is comming, or is it allready here?
Anyway, i have sort of a plan with this board, which i wont explain in all its glory :twisted:
The question at hand is:
How much code would it take to turn this board in to a network storage device?

The plan is really to make two states of "on" avalible, one just working as a network storage, an the other working as (its a secret). :twisted:

Anyway, i know close to nothing about network programming, so i though for starters it would be good to get some input on what is required, like tcp/ip and stuff.
Oh ya, of course it wont be running anything like linux or windows, that wouldnt be fun would it? :twisted:
User avatar
Kevin McGuire
Member
Member
Posts: 843
Joined: Tue Nov 09, 2004 12:00 am
Location: United States
Contact:

Post by Kevin McGuire »

I do not think you mean a device since I assume that word would generally refer to something physical although I assume you could describe that the electrical charges are the device running through the computer circuitry and only those charges relevant to this software is the actual device.

Never the less we already have a network storage device in that case? Since we store information that is accessible over a network.
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:

Post by Combuster »

A nice introduction to network programming is to write something like an IRC bot. Once you can dream up network code, feel free to take on any other networking task.

In the meantime, linux+samba? 8)
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
User avatar
Zacariaz
Member
Member
Posts: 1069
Joined: Tue May 22, 2007 2:36 pm
Contact:

Post by Zacariaz »

well, it was really just to get an idea and maybe a good discusion on how complicated it would have to be.

Somewhat complicated it seems ;)
User avatar
Kevin McGuire
Member
Member
Posts: 843
Joined: Tue Nov 09, 2004 12:00 am
Location: United States
Contact:

Post by Kevin McGuire »

Well. You might do something like this:


Open a UDP port on the server side.
Wait for packets.


Have four major commands for storage access use a header in the UDP packet such as:

Code: Select all

struct tNetStorageHdr
{
   uint8_t opcode;
};
Where if:
(opcode = 1) // OPEN
(opcode = 2) //CLOSE
(opcode = 3) // GET
(opcode = 4) // PUT


Then have a format for each opcode such that for OPEN:

Code: Select all

struct tNetStorageDataHdr
{
   uint32_t fileHandle;
   uint32_t filePos;
   uint32_t length;
};
void GotPacket(void *data)
{
   struct tNetStorageHdr *hdr = (struct tNetStorageHdr*)data;
   switch(hdr->opcode)
   {
      case 1:
         mode = *((uint32_t*)&hdr[1]);
         filename = *((uint8_t*)( ((uintptr_t)&hdr[1]) + sizeof(uint32_t) );
         // make sure it is okay to open it if someone else already has it opened.
         // make entry who opened this file. 
         // send back packet with fileHandle
        break;
      case 2:
         fileHandle = *((uint32_t*)&hdr[1]);
         // close file with handle
         break;
      case 3:
         struct tNetStorageDataHdr *dhdr = (struct tNetStorageDataHdr*)&hdr[1];
        /// check if file handle is opened
        /// read data specified
        /// send packet back with data
        break;
      case 3:
        /// same as READ, but in reverse.
   }
}

The basic idea is to have:
CLIENT -> SERVER -> CLIENT
OPEN -> ... -> RESULT
CLOSE -> ... -> RESULT
READ -> ... -> RESULT
WRITE -> ... -> RESULT


Then keep reusing that NetStorageHdr so that you have a base in which to determine what type of packet something is. The client will need to implement a blocking until it gets a result packet.

// the client sends a packet with ...
send(socketDescriptor, buffer, bufferLength, 0);
// waits for the result ..
recvLen = recv(socketDescriptor, buffer, bufferMaxLength, 0);
// hands result back to core function


The OPEN and CLOSE help with:
  • Access Control
  • Earlier Error Control
  • Increased Network And CPU Performance
Since they need to work with a descriptor which is a short identification for the actual filename you do not have to transmit the whole entire filename in a result or command packet. It allows a client to know there is a problem with a file before it has to allocate buffers and issue a read or write command. It allows clients to lock files or use certain modes to control access to that file while they are accessing it.

If you are working on linux you can at a console type:
man socket

This should get you started in the right direction to using sockets.
Post Reply