Various manual pages commonly exemplify FIFOs being opened in the /tmp directory, but they do not share a common naming convention. When I list the contents of my /tmp dir' I get nothing but directories named like /tmp/ssh-5oRuBPhI9lv9. Is there a convention, especially/specifically for IPC?
There is no official naming convention.
Sure, when using FIFOs, you will need some convention, since FIFOs are typically used for process communication between unrelated processes. So the name must be known to the different processes, which implies you have to follow some sort of convention, but it's your call.
The reason you see directories and files with mysterious names in /tmp is usually the result of the corresponding processes calling mkstemp(3) or mkdtemp(3). These functions atomically generate a unique name and create the corresponding file / directory.
If for some reason you want your FIFO to have a similar name, you can generate a unique name with tmpnam(3) and then pass that name to mkfifo(3). But note that there is a window of time between the call to tmpnam(3) and the call to mkfifo(3) where another process could create a file with the same name (and then mkfifo(3) would fail). If that's a problem, you could instead atomically create a temporary directory with mkdtemp(3) and then create the FIFO inside that directory with a name of your choice.
The reason there is no sure way to atomically generate and create a temporary, uniquely named FIFO is that FIFOs are used as rendezvous points for unrelated processes, so in general the name must be known a priori. Having a FIFO with a unique temporary name would make it harder for other processes to find it, which kind of defeats the purpose.
Related
Dennis Ritchie and Ken Thompson's paper UNIX Time-Sharing System mentions the following points
About i-number: A directory entry contains only a name for the associated file and a pointer to the file itself. This pointer is an integer called the i-number (for index number) of the file
About open and create system-calls: The returned value (of open and create) is called a file descriptor. It is a small integer used to identify the file in subsequent calls
Purpose of open/create: The purpose of an open or create system call is to turn the path name given by the user into an i-number by searching the explicitly or implicitly named directories
Does this mean that the file descriptor is just the i-number of a file? Or am I missing something?
A file descriptor in UNIX is basically just an index into the array of open files for the current process.
An inode number is an index into the inode table for the file system.
So they're basically just integers, indexes into an array, but they are indexes into completely different, unrelated arrays. So there is no connection between them.
To add to Chris Dodd's answer, not only are inode numbers and file descriptor numbers not directly related, it wouldn't be practical for them to be.
Inode numbers are unique to each file system. Imagine if you opened fileA on a file system (say, /mnt) with inode number 100, and in the same process also opened fileB on another filesystem (say, /mnt2) which also happened to have inode number 100. What should the file descriptors be in that case?
Using System V shared memory IPC requires calls to the following two functions:
int shmget(key_t key, size_t size, int shmflg);
void *shmat(int shmid, const void *shmaddr, int shmflg);
Why are they designed to be separate, instead of having a single function that accepts these arguments, performs both functions and simply returns the address?
We can consider files as an analogy. open on a string (the file path) gives us a file descriptor, and we use that to read/write from the file. We close on the file descriptor when we're done. This design seems natural, we don't have to open with a string to get a descriptor, and then attach to the descriptor.
As an example of what I have in mind, take a look at the FreeBSD sendmail shared memory implementation.
This kind of separation (shm_open and mmap) also exists with POSIX shared memory, but the reason was that mmap existed before shm_open was implemented and could be reused, and mmap requires a descriptor (source: UNIX Network Programming Vol. 2, R. Stevens, chapter 13, page 326).
Shared memory is probably one of the fastest ways of allowing for IPC as data need not be copied, the problem associated with it though is synchronizing access between multiple threads. You could do this using semaphores or record locks , we end up using the later in unix fro shared memory even though they are not as efficient as they are simple, the system cleans up well, and you don't need some of the bling that semaphores bring along.
Lets look into how these work to understand why they are implemented as such.
In comes the shmid_ds used by the linux kernel (http://www.tldp.org/LDP/lpg/node68.html)
the shm_nattch is the unsigned int counter for current attaches. shmget gets you an shm id and sets stuff like the ipc_perm , dates, pid, atime ctime, request of the segment size (shm_segsz)
next the shmctl kicks in and does stuff for ipc using IPC_STAT, IPC_RMID, IPC_SET like setting perms, getting or removing shm_id for a segment or even locking or unlocking it.
Once the segment is ready shmat is used by a process to attach to its address space, depending on the flags and address parameters. Once it attaches the kernel increments the shm_nattch. When detaching we call shmdt to detach . Removal of the identifier and the associated data structure is not automated some process has to do this calling shmctl with the IPC_RMID and depending on shm_perm
As you can see this is all very similar to how one would use semaphores and the implementation makes sense.
One possible reason I could think of is this:
(From the manpage of shmget)
After a fork(2) the child inherits the attached shared memory segments.
After an execve(2) all attached shared memory segments are detached from the process.
Upon _exit(2) all attached shared memory segments are detached from the process.
Well, technically attaching and detaching is basic reference counting on the shared memory segment that is reserved during shmget.
The functionalities of allocating the shared memory segment, via shmget and reference counting them (up or down, via shmat and shmdt respectively), are separate so that, code can be reused during fork and exec.
If they were both packed into the same function, you would anyways need a separate function, which just does reference counting (to be invoked during fork/exec). So, I think this design is simply to promote code reuse, and avoid code duplication.
I'm new on Java Card applications. At this moment I would like to store a hash table (dictionary) that contains the configuration of a terminal that reads this type of cards. If the hash table has values, those must be retrieved to the terminal (I think using APDU's right?) but also if there are no values, the terminal must create a "default" initial configuration.
Is it possible to do this? If it is, how? Maybe there is an applet ready for that (like Musclecard for key generation and signing) but I haven't found any.
Any advice? Thanks!
Java Card is pretty limited regarding support for data structures. It has a few basic types such as byte and short and optionally int, which is not used anywhere in the classic API. For those types you can generate two types of transient (RAM) arrays using JCSystem.makeTransientByteArray() and friends. Furthermore, the default byte[], short[] and Object[] created using new are stored in EEPROM.
The Object class in Java Card has been stripped down as well. This means that there is no such thing as hashCode(). If it was present then you would run into problems as the Java SE version of hashCode() returns an integer, which is probably not present. All defined data containers are either smart card or security related (e.g. the APDU and Key classes).
So basically, if you want to create a HashMap - the common type of dictionary on Java SE - then you will have to create it yourself. It is in that case a good idea to define a Hashable interface that classes can implement to act as a key. The structures should be generated in the right type of memory. For the kind of application you specify you probably need persistent memory, which is kind of the default for object instances created using the new key word.
Personally, I would make very sure you need a hashCode() method for your solution. It is probably easier to create an Object array and simply iterate over the elements.
Since there is no hash table in the smart card, you can store the terminal configurations in byte arrays. The smart card only stores the configuration (and optionally protect the data), and the instruction to get stored configuration or to update it shall be sent by terminal via APDU command.
Suggestion 1
Put your configuration in a Linear Fixed EF, if the card supports file system. No applet needs to be created/installed. It's the terminal job to read all records of the file to determine whether a configuration exist or not, and to write configuration into the file using standard APDU (UPDATE RECORD, READ RECORD).
NOTE:
set record length as number of terminal configuration bytes
number of records denotes the number of configurations that can be stored
you can put initial condition to indicate that the record is unused, e.g. 00...00
Suggestion 2
Create your own javacard applet. The applet must handle at least three proprietary APDUs:
Get list of terminal configurations
Update a record of terminal configuration
Delete a record of terminal configuration
NOTE:
You need to handle how to store and return the bytes between APDU format and your storage
I am writing an application which uses the DCM MKDIR, We save our images in little bigger name, but when I am trying to use the DCMMKDIR application, which is asking me to input file name max 8 characters.
Presently, I am planning to rename my Images starting from 1 to N. But remapping these images to known names(on the disk) will be bit difficult(I feel).
are there are any other methods/process to achieve the same.
The restriction of the filename to eight characters is derived from the DICOM Standard to ensure compatibility with applications that support e.g. only ISO 9660 as a file system for CDs.
About the naming you can have a look at the specifications the german CD Testat (http://www.dicom-cd.de/docs/DRG-RequirementsSpecification-2006.pdf). As a vendor you can be certified to conform to certain standards for interoperability of patient CDs which is currently the most common usage of DICOMDIRs.
The DICOMDIR file generated by DCMMKDIR is mainly a kind of index to tell an application, what DICOM files in a certain directory exist and this kind of file structure is usually more common for transfer media.
It is very common to use subdirectories to circumvent the restriction on max 8 length filenames. For example, a file could be 20110331/183421/000001 which would identify it properly with date, time and index without exceeding the somewhat arcane filename limit.
There are two really simple ways to let one program send a stream of data to another:
Unix pipe, or TCP socket, or something like that. This requires constant attention by consumer program, or producer program will block. Even increasing buffers their typically tiny defaults, it's still a huge problem.
Plain files - producer program appends with O_APPEND, consumer just reads whatever new data became available at its convenience. This doesn't require any synchronization (as long as diskspace is available), but Unix files only support truncating at the end, not at beginning, so it will fill up disk until both programs quit.
Is there a simple way to have it both ways, with data stored on disk until it gets read, and then freed? Obviously programs could communicate via database server or something like that, and not have this problem, but I'm looking for something that integrates well with normal Unix piping.
A relatively simple hand-rolled solution.
You could have the producer create files and keep writing until it gets to a certain size/number of record, whatever suits your application. The producer then closes the file and starts a new one with an agreed naming algorithm.
The consumer reads new records from a file then when it gets to the agreed maximum size closes and unlinks it and then opens the next one.
If your data can be split into blocks or transactions of some sort, you can use the file method for this with a serial number. The data producer would store the first megabyte of data in outfile.1, the next in outfile.2 etc. The consumer can read the files in order and delete them when read. Thus you get something like your second method, with cleanup along the way.
You should probably wrap all this in a library, so that from the applications point of view this is a pipe of some sort.
You should read some documentation on socat. You can use it to bridge the gap between tcp sockets, fifo files, pipes, stdio and others.
If you're feeling lazy, there's some nice examples of useful commands.
I'm not aware of anything, but it shouldn't be too hard to write a small utility that takes a directory as an argument (or uses $TMPDIR); and, uses select/poll to multiplex between reading from stdin, paging to a series of temporary files, and writing to stdout.