transfer binary over socket

This is a discussion on transfer binary over socket within the Networking/Device Communication forums, part of the General Programming Boards category; As I mentioned, I didn't think that was the issue, I am just issuing you a warning in more human ...

  1. #16
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    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()........

  2. #17
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by MK27 View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #18
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by robwhit View Post
    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.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  4. #19
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    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().

  5. #20
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by master5001 View Post
    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").
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  6. #21
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    once you fdopen() you should be using fwrite() anyway. But I somehow doubt that is the real problem.

  7. #22
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by master5001 View Post
    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.
    Last edited by MK27; 10-08-2008 at 06:10 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  8. #23
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    Ah ok. Well is fdopen() failed because of an invalid descriptor, then anything done with that descriptor should be equally ineffective, right? So why are you getting an invalid socket to begin with becomes the question. I don't believe you can use bind with AF_LOCAL. I am going to see what I can find. Double check the socket you are making to make sure it is even valid.

  9. #24
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    Ok yeah I am really starting to think the problem is with how you create your socket to begin with. I am not as familiar with AF_LOCAL to be trouble shooting your code by hand at this point. So I did read some manual pages to see what that address family does support, and it looks like there are a few things that it doesn't necessarily allow. You are probably doing something outside of the scope of that kind of socket.

  10. #25
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by master5001 View Post
    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
    Last edited by MK27; 10-08-2008 at 06:21 PM.

  11. #26
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    I couldn't find any formal documentation behind binding local sockets. Ok so it is valid (obviously) then perhaps fdopen() simply doesn't support that kind of socket. Ok so lets just remove fdopen() from the picture, does your code work if you comment out those lines of code?

  12. #27
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    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
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  13. #28
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    I am thinking it is an issue of the type of connection you are creating not being supported by fdopen(). And yes, conventional wisdom suggests that fdopen() should work. However, evidence seems to suggest otherwise (which is a kick in the teeth when these things happen).

    Try making a non-local connection and seeing if fdopen() will work. Why not rebuild your kernel to support the support fdopen() with AF_LOCAL.

  14. #29
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by master5001 View Post
    Why not rebuild your kernel to support the support fdopen() with AF_LOCAL.
    Probably I should try this first.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  15. #30
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    Just google your kernel version, OS, and the problem. Usually someone out there will tell you exactly which flags will need to be set for this. Unless you like rooting through your kernel's source code. Which is fine if you do, you are a better man than I if so.

Page 2 of 3 FirstFirst 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Header File Question(s)
    By AQWst in forum C++ Programming
    Replies: 10
    Last Post: 12-23-2004, 10:31 PM
  2. Creation of Menu problem
    By AQWst in forum C Programming
    Replies: 8
    Last Post: 11-24-2004, 08:44 PM
  3. Binary Search Trees Part III
    By Prelude in forum A Brief History of Cprogramming.com
    Replies: 16
    Last Post: 10-02-2004, 03:00 PM
  4. Tutorial review
    By Prelude in forum A Brief History of Cprogramming.com
    Replies: 11
    Last Post: 03-22-2004, 08:40 PM
  5. Request for comments
    By Prelude in forum A Brief History of Cprogramming.com
    Replies: 15
    Last Post: 01-02-2004, 09:33 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21