Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17


Winsock recvfrom, message length

Posted on 2004-04-17
Medium Priority
Last Modified: 2013-12-03
I'm porting a unix socket (UDP) app to windows. On unix, recvfrom will return the length of the message (even if it didn't fit in the buffer i passed to the function). I need to obtain the length of the incoming message, but this seems to be somehow messed up in the MS API, which returns -1 on failure and never seems to be able to give me the message length. On success, of course it gives me the actual number of bytes I got. However this is rather uninteresting since by then I've obviously already allocated a proper buffer. I need to know ahead of time what size buffer is needed to hold the message. I'd be very happy if someone could tell me what function I need to use to do this on windows ASAP.
Question by:limestar
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
  • 2
  • 2

Accepted Solution

aib_42 earned 2000 total points
ID: 10858120
You might want to take a look at the ioctlsocket() function. Particularly, the "FIONREAD" command, which you would probably implement as:
if (ioctlsocket(mysocket, FIONREAD, &nextreadsize)) { error } where nextreadsize is an unsigned long parameter, which will hopefully hold the length of the buffer you are going to read.

This is directly from MSDN at [ ]:

Use to determine the amount of data pending in the network's input buffer that can be read from socket s. The argp parameter points to an unsigned long value in which ioctlsocket stores the result. FIONREAD returns the amount of data that can be read in a single call to the recv function, which may not be the same as the total amount of data queued on the socket. If s is message oriented (for example, type SOCK_DGRAM), FIONREAD still returns the amount of pending data in the network buffer, however, the amount that can actually be read in a single call to the recv function is limited to the data size written in the send or sendto function call.

Expert Comment

ID: 10861790

Or use MSG_PEEK flag with recvfrom() call. This would return the number of bytes pending to recv.

But, I doubt if your original question is valid. This is what I read on recvfrom manual (on Solaris)

     These calls return the number of bytes received, or -1 if an
     error occurred.

It says recvfrom() returns the number of bytes received, not the number of bytes to receive.
Logically, that is the way it should work. recvfrom() call should give you the number of bytes received.
- Just like read() fread() etc.

Check out the code once again and see is that is correct .


Expert Comment

ID: 10861923
Ah yeah, forgot to mention MSG_PEEK...

It is funny how the text ".....and the function returns the number of bytes currently pending to receive." (in the description of the MSG_PEEK flag) only appears in the more recent versions of the WIN32 SDK Help.
Nothing ever in the clear!

This technical paper will help you implement VMware’s VM encryption as well as implement Veeam encryption which together will achieve the nothing ever in the clear goal. If a bad guy steals VMs, backups or traffic they get nothing.


Author Comment

ID: 10862568
Well, if you'd actually have read the original question except jumping madly for the points, you'd have seen that I stated clearly that thats just what we do on unix-based systems. However, MS has f**ked up their port of the sockets lib, so that recvfrom() returns SOCKET_ERROR instead of something proper (regardless of flags passed to it).

Anyway, thanks to aib_42 for the suggestion, I'll try it out later today and accept the answer if it works out.

Expert Comment

ID: 10862759

>> Well, if you'd actually have read the original question except jumping madly for the points,
>> you'd have seen that I stated clearly that thats just
>> what we do on unix-based systems.

duh!  I guess I knew that !!
May be you should do a little more eyeballing on others commenst before you add in more "stars" into your comments.

What I was trying to say was I am not sure if unix returns the number of bytes in the buffer - not the bytes actually read
and thats why I pasted the "man" page.

FYI 1 : This group is "Programming_Platforms/Win_Prog" meaning people will assume all questions are realted to windows.

FYI 2 : most of the socket library calls are similar in winsows and unix. So, when I said MSG_PEEK, it applies to Win32 as well.

FYI 3: People will post comments to all interesting questions even if there are only 50 points. ( I can see that from your own profile :)

FYI 4: There are people cursing MS because they know the in and out of the Windows system.
I have seen other people cursing too - may be just for the sake of cursing. :)


Author Comment

ID: 10862972
Right. My point was just that the socket library calls *look* similar on unix and windows. However, after some time programming winsock2, you'll gather rather quickly that it doesn't behave right.

1. Of course. This question is strictly windows. It works fine on unix, and I want to know how to get a certain functionallity out of the windows socket library.

2. They look the same. However, they don't work the same. Like I said, MSG_PEEK does NOT work the correct way in Win32, because recvfrom() will *still* return SOCKET_ERROR instead of the actual amount of bytes in the buffer. I guess I should've mentioned in the original code that the flag to the call was originally MSG_PEEK. This doesn't work however. MSDN is rather unclear on the subject, but after reading it several times you'll actually come to the conclusion that one possible way of interpreting it is that setting MSG_PEEK only returns the number of bytes if they were actually copied.

3. Of course. But you must also agree that alot of people will point whatever BS into a 500 pt question hoping to get the points even though they didn't even nearly answer the question....

4. I've done enough Win32 programming to curse MS with a good reason. Try the error conditions of the LoadLibrary() calls for instance. What happens if you run it on an invalid file? Error code? Nope, message box saying the user should check their installation diskette. The messed up API they call Win32 makes my work a big pain.

Check it out if you're too lazy to write the test app yourself. I find it rather entertaining:

Btw, the points of this question were not set because I beleived it difficult - it was set because I needed the solution ASAP. Sorry if I came across the wrong way.

Featured Post

On Demand Webinar: Networking for the Cloud Era

Ready to improve network connectivity? Watch this webinar to learn how SD-WANs and a one-click instant connect tool can boost provisions, deployment, and management of your cloud connection.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This article shows how to make a Windows 7 gadget that extends its U/I with a flyout panel -- a window that pops out next to the gadget.  The example gadget shows several additional techniques:  How to automatically resize a gadget or flyout panel t…
zlib is a free compression library (a DLL) on which the popular gzip utility is built.  In this article, we'll see how to use the zlib functions to compress and decompress data in memory; that is, without needing to use a temporary file.  We'll be c…
This is Part 3 in a 3-part series on Experts Exchange to discuss error handling in VBA code written for Excel. Part 1 of this series discussed basic error handling code using VBA.…
This is my first video review of Microsoft Bookings, I will be doing a part two with a bit more information, but wanted to get this out to you folks.

721 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question