I'm using the miniboa library for non-blocking telnet-style socket programming.
The library includes a demo of a simple chat server.
On line 809, in the poll() function, the system uses the select.select() function. When running the demo server in the miniboa.py file, the server doesn't block on this function; it executes and continues without skipping a beat.
I am writing a MUD with networking code based on that very code, however in my MUD server (see the link below), the server blocks on that very same call, every single time.
In my MUD's network.py library, on line 68, the server executes the poll() function. This is the same function that executes in the simple chat server, except when it executes in my MUD server, it blocks on the select.select() call.
I don't know why it's blocking, but it's blocking, and the loop doesn't repeat until after a user sends data. If nobody sends anything, the server just waits.
Does anyone have any idea why this might be? I'll be happy to answer any questions I can about the code, and it's open-source so you can see all the code and play with it if you want.
I appreciate any help you all might be able to provide. I've been dreaming of making a MUD since I first played one as a kid many years ago, and I'm afraid to continue working on it until I get this bug sorted. Until I fix this bug, the server won't work the way it ought to.
TL;DR: My server is getting stuck in the select.select() function while it waits for client input, though it's not supposed to pause there. I can't figure out why it's blocking.
Related
I've been scouring for an hour to find an answer on this one -- got close, but not quite there.
The issue is that I'm using this basic approach to implement a socket server, but (of course) it hits the line with the accept() and freezes there. What I want is to be able to have the user click a checkbox control in a Tkinter GUI and have the socket be listening, or closed, on demand. A flag/semaphore to control the while loop doesn't help by itself; in concert with that, I also have to send a 'dummy' connection to get the server to iterate through the loop instead of just sitting at the accept() forever. Which would work of course, but it just feels klunky.
After much effort I found this article but the solution -- while it's a nice one -- still seems to still depend on the connection handler to raise the event that triggers the exit. Which in turn means that I'd still need some kind of dummy connection to make it happen, instead of being able to interrupt/destroy/whatever the server socket while it's stopped at the accept().
So is there any way to get around needing a connection before you can get the server socket closed?
I am trying to understand the IO provided by akka. I started another question for this issue.
I found a simple example on how to use akka IO. I reimplemented it and started it. Now I am wondering why only the first message of the session is printed.
Can somebody please explain what state(socket)(Chunk(bytes)) is doing and how I could sent a message to another Actor of the ActorSystem instead?
Edit
I figured out, that the actor just takes a single input and process it by just printing it to the console. That leads me to another question: How can I make the actor take multiple inputs and process them? I connected to the server via putty and if I hit enter one time it processes the input as expected, but if I send another line of input it only stores the input. Where do I have to run flatMap, so it processes the next line of input? I tried it inside of the Read(socket, bytes) case, but it didn't work.
The example you are trying to understand is a bit more advanced, mainly because it is dealing with socket based communication. If you are actually interested in that kind of stuff, I suggest you read the documentation where the example from the blog seems to originate from.
In any case, before you do that, a good read would be Getting Started Tutorial which explains the fundamentals of Akka actors and gives you some actors to play with.
we're going to develop a game with internet multiplayer support. since it's an interactive game I know I have to use UDP to reduce connection latency, but I'm wondering what are the possible errors that may occur in a package delivered using UDP connection? everywhere I looked they say UDP provides "Best effort delivery", but no one does give a complete explanation what does it mean. after reading some article there are two questions that I still have:
Is it possible to send a package and receive part of it at the other end of connection?
if your answer to first quesiton is true what would happen to the next packages? should I wait for the rest of package or can I assume next package start with my next recv call?
for our game I think we will need to send 4 packages of around 20 byte each second.
The most common thing that can happen is: one side sends a message, the other receives nothing.
Is it possible to send a package and receive part of it at the other
end of connection?
Not really, not even when the message is huge and it gets fragmented. Unlike in TCP, in UDP every message is independent. You either get it entirely or nothing at all.
So what you should do it just recvfrom things in a loop and process them. Obviously you should make your application impervious to message loss such that a missing message doesn't crash it.
I've made a simple dummy server/dummy client program using IOCP for some testing/profiling purpose. (And I also wanted to note that I'm new to asynchronous network programming)
It looks like the server works well with original client, but when the dummy client tries to connect to the server with ConnectEx function, IOCP Worker thread still gets blocked by GetQueuedCompletionStatus function and never returns result while the server succeeds in accepting the connection.
What is the problem and/or the reason, and how should I do to solve this problem?
I think you answer your own question with your comment.
Your sequence of events is incorrect, you say that you Bind, ConnectEx, Associate to IOCP.
You should Bind, associate the socket with the IOCP and THEN call ConnectEx.
Even after you associate your accepted socket to IOCP, your worker thread will remain blocked on GetQueuedCompletionStatus untill you post an "unlocking" completion event.
Completion events for receive/write operation wo'nt be sent by the system unless you "unlock" your new socket.
For details ckeck the source code of Push Framework http://www.pushframework.com It is a C++ network application framework using IOCP.
The "unlocking" trick exists in the "IOCPQueue" class.
I was recently approached by my management with an interesting problem - where I am pretty sure I am telling my bosses the correct information but I really want to make sure I am telling them the correct stuff.
I am being asked to develop some software that has this function:
An application at one location is constantly processing real-time data every second and only generates data if the underlying data has changed in any way.
On the event that the data has changed send the results to another box over a network
Maintains a persistent connection between the both machines, altering the remote box if for some reason the network connection went down
From what I understand, I imagine that I need to do some reading on doing some sort of TCP/IP socket-level stuff. That way if the connection is dropped the remote location will be aware that the data it has received may be stale.
However management seems to be very convinced that this can be accomplished using SOAP. I was under the impression that SOAP is more or less a way for a client to initiate a procedure from a server and get some results via the HTTP protocol. Am I wrong in assuming this? I haven't been able to find much information on how SOAP might be able to solve a problem like this.
I feel like a lot of people around my office are using SOAP as a buzzword and that has generated a bit of confusion over what SOAP actually is - and is capable of.
Any thoughts on how to accomplish this task would be appreciated!
I think SOAP is the wrong tool. SOAP is a spec for exchanging structured data. For your problem, the simplest thing would be to write a program to just transfer data and figure out if the other end is alive. Sockets are a good way to go. There are lots of socket programming tutorials on the net. Pick your language, and ask Mr. Google. Write a couple of demo programs to teach yourself how it works. Ask if you have more specific questions.
For the problem, you'll need a sender and a receiver. The sender sends data when it gets it, the receiver waits for data and hands it off when it arrives. Get that working first. Next, add in heartbeats; a message that says "I'm alive", sent periodically. Get that working next. You'll need to be determine the exact behavior you want -- should both sides send heartbeats to the other end, the maximum time you are willing to wait for a heartbeat, and what action you take should heartbeats stop arriving. The network connection can drop, the other end can crash, the other end can hang, and perhaps there are other conditions you should think about (e.g., what if the real time data is nonsense?). Figure out how to handle each condition, and code up the error handling. Test it out, and serve with a side of documentation.
SOAP certainly won't tell you when the data source goes down, though you could use "heartbeats" to add that.
Probably you are right and they are just repeating a buzz word, and don't actually know much about what SOAP is or does or have any real argument for why it ought to be used here.