Thread: transfer binary over socket

Originally Posted by MK27

On my computer I am unlikely to recieve file descriptor 33454 (etc). But I tried switching "short int" to "int" -- same thing.

Even if it's UNLIKELY, being correct is important when it comes to computers.

--
Mats

Originally Posted by robwhit

No, don't take out the closes, just take out the fclose you fdopened.

that fclose is on the steam which read the file into a buffer. It's irrelevant to all the socket stuff. The buffer already contains the file, then gets transmitted.

Originally Posted by master5001

Here is the deal.... fclose() will clean up after the FILE * structure produced by fdopen(). close() will just close the descriptor you have opened. This is where Mats is free to jump in with a correction, but you should only call fclose().

Well, for argument's sake I tried it, and it didn't matter. Just to clarify, tho -- you do understand that

fclose(fstRO);

refers to

FILE *fstRO = fopen(argv[1], "rb")

and NOT

if ((sstOUT=fdopen(OUT,"w"))==NULL) perror("fdopen");

And: what file structure created by fdopen? The problem is that fdopen isn't creating anything, it returns NULL on an apparently bad descriptor, but the next command

write(OUT,buffer,bytes);

succeeds (OUT being the "Bad descriptor").

Originally Posted by master5001

As I mentioned, I didn't think that was the issue, I am just issuing you a warning in more human terms than your compiler issues warnings in. Because you will listen to us where your compiler fails to get through to you. And yeah your closes are all out of whack. And more importantly, your code doesn't look like it uses any of the C stream functionality at all... well except for fclose()........

I'm taking this to heart because I obviously want your advice. What do you mean by "your code doesn't look like it uses any of the C stream functionality at all":

Code:

        FILE *fstRO = fopen(argv[1], "rb"),  * sstOUT;
	FILE *fstW = fopen("/root/test/image.jpg", "wb");
	struct sockaddr addr;

	if (fstRO == NULL) {
		puts("valid filename required");
		return -1;}
	
	stat(argv[1],&finfo);
	bytes=finfo.st_size;
	buffer=malloc(bytes);
	buffer2=malloc(bytes);
	
	printf("%d\n",bytes);
	
	fread(buffer,bytes,1,fstRO);
	fclose(fstRO);

Is all the C stream functionality I could muster, except for the final buffer write and

Code:

if ((sstOUT=fdopen(OUT,"w"))==NULL) perror("fdopen");

which is just there to demonstrate that it doesn't work.

And what, pray tell, are my closes "out of whack" with?

ps. I didn't use fwrite because -- once again -- fdopen (there is only one) FAILED. The write is to the socket descriptor, not a stream.
pps. I just noticed that cboard will not accept "* sst" without the space, and instead replaced it with ........ perhaps I am haunted today.

Originally Posted by master5001

Double check the socket you are making to make sure it is even valid.

AHHHRGGHHH!!!! How many times do I have to point out that the fd is obviously valid because the file transfer DOES happen.

w/r/t bind, I'll check that out -- all the examples I found were INET, but nowhere in the GNU documentation does it say "don't bind local sockets".

[moment later] no, I guess you don't have to bind them, but it still works out the same way

But according to RobSeace, adminstrator of the unix socket forum (a little undercrowded, surprise) on developerweb, "the fdopen() trick SHOULD work fine, if you really wanted to go that route...But, it's really not necessary"

Which I didn't want to, I started out doing it because the file transferred on the descriptor with read/write is/was bum, etc. And again, according to all the sources (eg. Codeplug) that is the usual way to go and it should work.

Maybe it's my kernel

Originally Posted by master5001

Why not rebuild your kernel to support the support fdopen() with AF_LOCAL.

Probably I should try this first.