🔒 Locked

FIFO program

Started by a2k Apr 12, 2001 at 1:07 AM 3 replies 400+ views

Original Post

Apr 12, 2001 at 1:07 AM

my professor wants me to make a program that will read a file from disk, write it to a file, and also read from the same file at the same time. Now, he says to implement this as a FIFO buffer. but i have a few questions. why would i want to write this sort of file as a copy of it to another file "buffer"? wouldn't it be better to do the entire FIFO buffer in memory? i thought that's the way it was supposed to be done. also, wouldn't the program reading from the same file be a different program than that which writes to the file? i'm having difficulty in seeing the reason for this. what i'm supposed to try and accomplish is sending the the file to a buffer that will then read this "buffer" on disk across a network, and then save it over there. now, i think this was supposed to be a live stream MPEG file that i was supposed to be encapsulating in RTP, but i think he just said to copy the bytes of the MPEG file, and then send it across the network, where the streaming server is, and then the server will do the rest. so i'd just be sending a file from the "content creator" machine, and sending the content to the server machine to be distributed. this implementation that i describe above sounds pretty hokey to me. why can't you just open the MPEG file, send the file packets at a time with winsock, and then be done with it? why all this FIFO and external buffer file? i don't get it. thanks for any explanations. allan Edited by - a2k on April 12, 2001 2:10:21 AM

Stoffel

Apr 12, 2001 at 2:53 AM

Your professor sounds like a hardware guy, like me!! =) We do FIFOs at work all the time.

Why not the whole file at once? What if the file a gig, but you only want 1k of it? With a FIFO, you can set an arbitrary size that''s reasonably small so it can fit in your program without taking too many resources, but large enough so that it will cache parts of the file without excessive thrashing.

It also sounds to me like the point of the program is not a useful file utility, but to get you used to FIFOs--queuing theory, etc. If you ever work with hardware, you will use FIFOs all the time. I cannot stress that enough.

Having the same program reading and writing to a file makes sense to me; generally, you want one application to read data, modify it, then write it, don''t you?

As for the second part of the question:
If your MPEG is large, say a full-length movie, you don''t want to wait to load the entire movie into memory. When the user clicks "send", you want it to grab the first chunk of that file and shoot it over the network, as instantaneously as possible. I''m not quite sure from your description what the difference is between using winsock and sending it from the content creator to the content server. Is this an actual application or is this more of an exercise?

a2k

Apr 12, 2001 at 11:12 AM

it's supposedly for a demonstration that will eventually turn out to be an actual application. we have the server software already, and i'm creating a VB gui for selecting the mpeg file to send to the content server.

but what i mean about the fifo is this.

okay, i have opened a file, and read in some bytes,
now, it's in memory. why can't i just send those bytes across the network straight from memory rather than write to another file and have another file pointer read from this file? isn't that redundant?

and if i were to create two file pointers (one for reading the file and writing to another file, and another for reading from this new "buffer" file, shouldn't these be two independent programs, not one program?

a2k

Edited by - a2k on April 12, 2001 12:14:42 PM

a2k

Apr 13, 2001 at 4:46 PM

anyone else know about FIFO before my topic gets kicked off the first page?

a2k

Mithrandir

Apr 13, 2001 at 11:28 PM

There are several implementations of FIFO queues that I have worked with:

The simplest to use (but has memory overhead) is a linked queue. It is a linked list with reduced functionality. The enqueue() operation appends a piece of data to the end of the list, and the dequeue() operation removes the first item in the list. The linked method also has the added feature of being size-independent.

Another method i''ve used is with a circular array (i''ve seen non-circular queues, but I''ve never seen a good use for them), in which the queue is an array which keeps track of the item count, the first index, and the last index. This has less memory overhead (because we have eliminated the linked list pointers), but these are generally not easily resizable.

The finer details of these methods should be somewhat easy to figure out, unless you don''t know basic data structure techniques... in which case I should ask, why are you implementing a FIFO if you dont know? heh...

===============================================
Have I no control, is my soul not mine?
Am I not just man, destiny defined?
Never to be ruled, nor held to heel!

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.