473,326 Members | 2,113 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

udp, datagram sockets

I'm trying to understand datagrams. My client program sends a message
to the server, and then the server infinitely loops over the recv() to
make sure all the data was received. I'm trying to use an * to signal
the end of the message, so that the server can break out of the
infinite while loop used to check the recv(). However, my server
repeatedly outputs the client message over and over again. Can anyone
tell me why?

When I start the server, I get the following debug output as
expected:

---------
debug: start outer while loop
#this infinite while loop endlessly listens for messages from the
client

debug: recv while loop
#this infinite while loop checks to make sure the whole message was
received
-----------

and then the recv() blocks and waits for data to be sent by the
client. But when I start the client, the server repeatedly outputs the
client message over and over again. My expectation was that after
processing the message from the client, the server would block the
next time it executed the recv() statement and wait for more data from
the client.

client:
----------
import socket

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

message = "hello*" #asterisk to delimit end of message
msg_size = len(message)
total_sent = 0

print "debug:", total_sent, msg_size

while total_sent < msg_size:
size_sent = s.sendto(message[total_sent:], ("localhost", 7777) )
total_sent += size_sent

print "debug:", total_sent, msg_size

print 'debug: while loop ended'
s.close()
-----------

Here's the client output:

-------------
debug: 0 6
debug: 6 6
debug: while loop ended
---------------
server:
------------------
import socket
import sys

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind(("", 7777))

try:
while True: #This loop listens endlessly for messages.
print "debug: start outer while loop"

#Receive messages from client:
my_list = []
while True: #This loop checks to see if the whole message was
received.
print "debug: recv while loop"

data = s.recv(1024)
my_list.append(data)

if data.rfind("*"):
message = "".join(my_list)
print "Received message:\n%s" % message[:-1]
break
#Send messages back to client:
total_sent = 0
while total_sent < len(message):
print "debug: send while loop"

size_sent = s.sendto(message[total_sent:], ("localhost",
7777) )
total_sent += size_sent

print "debug:", total_sent, len(message)

finally:
s.close()
--------------------------

Here's the server output:

---------------
debug: start outer while loop
debug: recv while loop
Received message:
hello
debug: send while loop
debug: 6 6
debug: start outer while loop
debug: recv while loop
Received message:
hello
debug: send while loop
debug: 6 6
.....
.....
.....
------------------

Aug 6 '07 #1
6 2332
On Monday 06 August 2007, 7stud wrote:
I'm trying to understand datagrams. My client program sends a message
to the server, and then the server infinitely loops over the recv() to
make sure all the data was received. I'm trying to use an * to signal
the end of the message, so that the server can break out of the
infinite while loop used to check the recv(). However, my server
repeatedly outputs the client message over and over again. Can anyone
tell me why?

When I start the server, I get the following debug output as
expected:

---------
debug: start outer while loop
#this infinite while loop endlessly listens for messages from the
client

debug: recv while loop
#this infinite while loop checks to make sure the whole message was
received
-----------

and then the recv() blocks and waits for data to be sent by the
client. But when I start the client, the server repeatedly outputs the
client message over and over again. My expectation was that after
processing the message from the client, the server would block the
next time it executed the recv() statement and wait for more data from
the client.

client:
----------
import socket

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

message = "hello*" #asterisk to delimit end of message
msg_size = len(message)
total_sent = 0

print "debug:", total_sent, msg_size

while total_sent < msg_size:
size_sent = s.sendto(message[total_sent:], ("localhost", 7777) )
total_sent += size_sent

print "debug:", total_sent, msg_size

print 'debug: while loop ended'
s.close()
-----------

Here's the client output:

-------------
debug: 0 6
debug: 6 6
debug: while loop ended
---------------
server:
------------------
import socket
import sys

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind(("", 7777))

try:
while True: #This loop listens endlessly for messages.
print "debug: start outer while loop"

#Receive messages from client:
my_list = []
while True: #This loop checks to see if the whole message was
received.
print "debug: recv while loop"

data = s.recv(1024)
my_list.append(data)

if data.rfind("*"):
message = "".join(my_list)
print "Received message:\n%s" % message[:-1]
break
#Send messages back to client:
total_sent = 0
while total_sent < len(message):
print "debug: send while loop"

size_sent = s.sendto(message[total_sent:], ("localhost",
7777) )
total_sent += size_sent

print "debug:", total_sent, len(message)

finally:
s.close()
--------------------------

Here's the server output:

---------------
debug: start outer while loop
debug: recv while loop
Received message:
hello
debug: send while loop
debug: 6 6
debug: start outer while loop
debug: recv while loop
Received message:
hello
debug: send while loop
debug: 6 6
....
....
....
------------------
You don't make any attempt to break out of the outer loop. (break breaks the
innermost loop)
Aug 6 '07 #2
On Aug 6, 10:59 am, Thomas Jollans <tho...@jollans.comwrote:
>
You don't make any attempt to break out of the outer loop. (break breaks the
innermost loop)
By design. My server stands ready to process any and all messages
forever. The problem I'm having is that my server processes the same
message forever.

Aug 6 '07 #3
On Aug 6, 11:05 am, Jean-Paul Calderone <exar...@divmod.comwrote:
>
The network is probably dropping some of your data, causing the server
to never see the termination marker.
As far as I can tell, the output disproves that notion. If the
termination character were somehow lost in transmission, then this
statement:

print "Received message:\n%s" % message[:-1]

would produce the output:
Received message:
hell

since the print statement chops off the last character of the received
data.

Aug 6 '07 #4
On Mon, 2007-08-06 at 09:03 -0700, 7stud wrote:
server:
------------------
import socket
import sys

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind(("", 7777))
[...]
#Send messages back to client:
total_sent = 0
while total_sent < len(message):
print "debug: send while loop"

size_sent = s.sendto(message[total_sent:], ("localhost",
7777) )
total_sent += size_sent

print "debug:", total_sent, len(message)
I don't think that sending the datagram to port 7777 on localhost sends
the message back to the client. I'm guessing the server is sending the
message back to itself, which throws it into the infinite feedback loop
you're experiencing.

HTH,

--
Carsten Haese
http://informixdb.sourceforge.net
Aug 6 '07 #5
On Aug 6, 1:27 pm, Carsten Haese <cars...@uniqsys.comwrote:
On Mon, 2007-08-06 at 09:03 -0700, 7stud wrote:
server:
------------------
import socket
import sys
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind(("", 7777))
[...]
#Send messages back to client:
total_sent = 0
while total_sent < len(message):
print "debug: send while loop"
size_sent = s.sendto(message[total_sent:], ("localhost",
7777) )
total_sent += size_sent
print "debug:", total_sent, len(message)

I don't think that sending the datagram to port 7777 on localhost sends
the message back to the client. I'm guessing the server is sending the
message back to itself, which throws it into the infinite feedback loop
you're experiencing.

HTH,

--
Carsten Haesehttp://informixdb.sourceforge.net
Yes, you want to use the socket.recvfrom() method, store the address,
and send the response to that address. Your code is indeed repeatedly
sending itself the received message.

You want to change
data = s.recv(1024)
to
data, recv_addr = s.recvfrom(1024)

and
size_sent = s.sendto(message[total_sent:], ("localhost",
7777) )
to
size_sent = s.sendto(message[total_sent:], recv_addr)

However, your client closes immediately after sending all its data, so
it will never receive that message.

Aug 6 '07 #6
On Aug 6, 1:27 pm, Carsten Haese <cars...@uniqsys.comwrote:
I don't think that sending the datagram to port 7777 on localhost sends
the message back to the client. I'm guessing the server is sending the
message back to itself, which throws it into the infinite feedback loop
you're experiencing.
Thanks.

On Aug 6, 2:14 pm, anethema <jefish...@gmail.comwrote:
Yes, you want to use the socket.recvfrom() method, store the address,
and send the response to that address. Your code is indeed repeatedly
sending itself the received message.

You want to change
> data = s.recv(1024)

to

data, recv_addr = s.recvfrom(1024)

and
> size_sent = s.sendto(message[total_sent:], ("localhost",
7777) )

to

size_sent = s.sendto(message[total_sent:], recv_addr)
Thanks for the details.

However, your client closes immediately after sending all its data, so
it will never receive that message.
Yes, I commented out the recv() part of the client to debug the
infinite loop I was experiencing. When I add that back to the client
everything works as it should.

Thanks to both of you again.

Aug 6 '07 #7

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Dave | last post by:
Hi, This is doubtless a really dumb question but is there an elegant way of reading numbers formatted as hex from a datgram? I get a datgram which contains values like this: ---DATAGRAM---...
0
by: Jonathan Ellis | last post by:
I seem to be running into a limit of 64 queued datagrams. This isn't a data buffer size; varying the size of the datagram makes no difference in the observed queue size. If more datagrams are...
4
by: Gregory Hassett | last post by:
Hello, Does anyone know how to get the maximum size of a datagram for a UDP Socket created via .NET's System.Net.Sockets.Socket class? Thanks!
6
by: Iain King | last post by:
Hi. I've been looking everywhere for this and can't find it, apologies if I'm being obtuse: How do I set the max datagram packet size? I'm using the socket module. It seem like it's hardcoded...
4
by: alberto.castellin | last post by:
Hi to all, I've this problem: I create a datagram socket. I create datagram socket with function 'Create'. The line of my code when I create is: m_pSocket->Create(port,SOCK_DGRAM,FD_READ |...
2
by: DaTurk | last post by:
I know in TCP if you send a message down the wire, the OS may lump subsequent messages into a buffer before sending it across the wire, for efficiency. But, will the OS do the same thing with UDP?...
1
by: greenxiar | last post by:
My code is below and the platform is Win2K3 R2: using System; using System.Net; using System.Net.Sockets; using System.Threading; namespace TechUDPBroadcast { class Program { static void...
1
by: sfncook | last post by:
Hi, As far as I can tell you can't call the accept function on a datagram socket. So why did this guy publish this sample code? http://www.codersource.net/winsock_tutorial_server_select_model.html...
8
by: babakandme | last post by:
How can I read IP Datagram? Should I write some Driver for that? Is there any special book about it? Thank you.
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.