Re: FILE* behaviour over BSD sockets - how?
From: Darko M. (mdanko_at_tesla.rcub.bg.ac.yu)
Date: 05/13/04
- Next message: Jem Berkes: "Re: FILE* behaviour over BSD sockets - how?"
- Previous message: Aurelian Melinte: "Re: FILE* behaviour over BSD sockets - how?"
- In reply to: Søren Hansen: "Re: FILE* behaviour over BSD sockets - how?"
- Next in thread: Jem Berkes: "Re: FILE* behaviour over BSD sockets - how?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 13 May 2004 07:58:05 -0700
> > Hello,
> >
> > I am looking to make a socket behave like a FILE*.
> >
> > The problem: I have to use a library (which I cannot modify) with an API
> > reading/writing records to FILE*. The data I have to read comes through a
> > socket. The socket has been set to blocking and I successfully
> > fdopen(socket). However, the API reads once in a while incomplete records
> > because the underlying socket calls seem to return as soon as there is a
> > packet to read but not when the whole requested number of bytes has been
> > read.
I have verified the behaviour of the fscanf function when it is
waiting for a string from the file pointer.
I made a server side program that executes fscanf( f, "%s", array ),
where the "f" argument is the one got from the fdopen(
socket_descriptor, "r" ).
The client side prints an array from the other side of the connection,
but does not print a separator, then sleeps for 10 seconds, then
prints another array and a separator.
After the first array from the client, the server normally sleeps and
waits for more. After the clients sends the other array AND the
separator, the server wakes up and prints the whole string. That means
that the stdlib works correct.
I thought that perhaps it's something about signals. So I put the
server to wait, the client to send the first string, and then throw a
signal to the server side ( I put the signal handler to execute an
empty block, so the read() would have been interrupted ). Nothing. The
server side sleeps as usual and waits for the rest. It waits until the
separator is found, and the separator only. Not event interrupt from a
signal can stop it ( unless the signal hasn't been handled by a
function that does something that would explicitely interrupt it in a
way ).
This same behaviour is got when it is waiting for a number (I checked
that too).
That gives me the conclusion that your problem is probably about bad
synchronization with the client (with the other side). You probably
send a separator from the other side, and you don't know you did. The
standard library hasn't got (as far as I know) something like
fnscanf(), to read an exact number of characters, so if I'm missing
something in the upper text, than I would suggest you rather use a
file descriptor calls set, than the standard library.
If you're actually not using the standard library functions set,
fscanf() etc. than suggest your programmer to repair the ones you're
using, so they handle interrupts properly etc.
I use Linux 2.4.22. Perhaps it matters, however, if you're using
another version. Although I don't think so, since it's the standard
library we're talking about, and it is STANDARD - as it's name
suggests :)
- Next message: Jem Berkes: "Re: FILE* behaviour over BSD sockets - how?"
- Previous message: Aurelian Melinte: "Re: FILE* behaviour over BSD sockets - how?"
- In reply to: Søren Hansen: "Re: FILE* behaviour over BSD sockets - how?"
- Next in thread: Jem Berkes: "Re: FILE* behaviour over BSD sockets - how?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
