Solved

socket

Posted on 2011-02-24
14
501 Views
Last Modified: 2012-05-11
I have a client server application:

Client) Continues listen and waits on recv()
Server) has 2 threads
      Thread 1) Continously sends data
      Thread 2) Send data every 30 secs.

I have noticed many times,
1) Thread 2 in Server simply waits for ever during send()...
2) As soon as thread 1 sends some data, thread 2 just finishes.

What could be going wrong?


Can the server simply send() even though client is not waiting on recv()
0
Comment
Question by:learningunix
  • 6
  • 3
  • 2
  • +2
14 Comments
 
LVL 9

Expert Comment

by:AriMc
ID: 34975815
Sending the source codes of your applications could help.

0
 

Author Comment

by:learningunix
ID: 34975832
This what I have noticed:

Thread 1 and Thread 2 both calls socket send() using

mutex_lock()
  send();
mutex_unlock()

It looks like Thread 2 is holding the lock and waiting on send() forever (looks like client is not receiving at this time. What is the max data that can be send over the line?)
Because of this Thread 1 can't hold the lock.

0
 

Author Comment

by:learningunix
ID: 34975925
actually the other way, thread 1 continously sends data and after some time it just simply waits on send()
(probably client is not receiving). thread 1 is holding lock.

as a result thread 2 is not able to acquire lock.

The only reason I need thread 2 is to send a mesaage to client that i am still alive but thread 1 is already stuck in send()
0
 

Author Comment

by:learningunix
ID: 34975947
the whole point of thread 2 is to make sure the connection is kept alive by sending message every 30 secs. in case thread 1 is taking some time.

However if the thread 1 itself can''t send anymore data (probably either client is not receiving or poll() is not allowing me to write ) how can thread 1 send any data.
0
 

Author Comment

by:learningunix
ID: 34976152
I need a way to keep the socket connection alive so that thread 1 does not throws exception
0
 
LVL 8

Expert Comment

by:ssnkumar
ID: 34977011
If you don't want to block on send, then open the socket in non-blocking mode.
Also, you can use write() system call instead of send().

From the send() manpage, regarding blocking, this is what it says:
When  the message does not fit into the send buffer of the socket, send() normally blocks, unless the socket has been placed in non-blocking I/O mode.  In non-blocking mode it would return EAGAIN in this case.
0
 
LVL 6

Expert Comment

by:de2Zotjes
ID: 34977593
If you created a thread just to ensure that a connection is not dropped due to inactivity you should instead look at the OS facilities: http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/index.html.

The very short summary of that howto is that the kernel can take care of this for you. And that you can set this up when creating the socket.
0
What Is Threat Intelligence?

Threat intelligence is often discussed, but rarely understood. Starting with a precise definition, along with clear business goals, is essential.

 
LVL 53

Accepted Solution

by:
Infinity08 earned 500 total points
ID: 34977788
A few things that will probably help you figure out what's going wrong, and fix the problem :

(a) make sure that both threads use the same socket (id) - do that by using a shared variable

(b) make sure that both threads use a shared mutex (or other synchronization primitive) to control access to the shared socket

(c) make sure that both threads lock the mutex (if using a mutex) before each use of the socket, and release it as soon as they have finished using it. When using a loop, make sure to do the locking and releasing inside the loop (so as not to lock it for too long)

(d) always check all return values and/or error code for all function calls
0
 

Author Comment

by:learningunix
ID: 34979276
@infinity.

1. Yes both the the thread uses same socket desciptor
2. Before sending I use mutex to lock it and then release the lock
3. The issue is Thread 1 is somehow blocked after sending a large number of data?
4. Because of this my Thread 2 can't get lock on mutex and is not able to send keepalive packet
0
 
LVL 53

Expert Comment

by:Infinity08
ID: 34979414
>> 3. The issue is Thread 1 is somehow blocked after sending a large number of data?

But the question is : where is it blocked and why ?

If it really is the send that is blocking, then ssnkumar's suggestion to use a non-blocking socket (and check all return codes) would resolve this for you.

If it's blocking on the lock, then there might be a deadlock, which you'll have to investigate.

If it's blocking somewhere else, then you need to find out where.

As I said : make sure to check and verify all return and error codes.
0
 
LVL 8

Expert Comment

by:ssnkumar
ID: 34981639
> 3. The issue is Thread 1 is somehow blocked after sending a large number of data?
Put a printf() before and after send() call and see if it is blocked on send().
If yes, then either you need to change the receiving socket, so that it does a recv() to get the data.

So, to continue to debug, you should find out, which call is blocking?
0
 
LVL 6

Expert Comment

by:de2Zotjes
ID: 34986256
And again: let the kernel handle this. Keepalive packets are put on the line when needed, but you will not have problems in your applications (server and client) with handling data that was sent as keepalive data.

looks like a typical case of reinventing the wheel..
0
 
LVL 53

Expert Comment

by:Infinity08
ID: 34986303
Sure, de2Zotjes, but it's still interesting to know what caused the issue, because it might be impacting other aspects of the code too.
0
 

Author Closing Comment

by:learningunix
ID: 35037867
locks were not released properly. I found out. Thx
0

Featured Post

How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Join & Write a Comment

Introduction This article is a continuation of the C/C++ Visual Studio Express debugger series. Part 1 provided a quick start guide in using the debugger. Part 2 focused on additional topics in breakpoints. As your assignments become a little more …
It’s 2016. Password authentication should be dead — or at least close to dying. But, unfortunately, it has not traversed Quagga stage yet. Using password authentication is like laundering hotel guest linens with a washboard — it’s Passé.
The goal of the video will be to teach the user the difference and consequence of passing data by value vs passing data by reference in C++. An example of passing data by value as well as an example of passing data by reference will be be given. Bot…
The viewer will learn how to use the return statement in functions in C++. The video will also teach the user how to pass data to a function and have the function return data back for further processing.

747 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

Need Help in Real-Time?

Connect with top rated Experts

10 Experts available now in Live!

Get 1:1 Help Now