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.
Related
First of all, I am a beginner in Akka. I have an Actor (in Scala), which after receiving a message:
may not send anything
may send a message
may send multiple messages
I would like to test it, without the need for timers.
As far as I managed to dig, I can use the ? function of a TestActorRef, then wait for the Future. I don't know if this will time out if nothing is sent (I suspect it will, because it has an implicit timeout parameter), but it can't wait for multiple messages.
I can also use the recieve functions in the TestKit, however that will time out when it ensures that no message is received, which will make my tests slow and less robust.
What I need (or I think I need), is something that can send in messages, then run receive on the Actor until there are messages in its message queue, then check what it has sent out.
Can you tell me a way to achieve this, or point out what should I do in a different way?
You should use http://doc.akka.io/docs/akka/snapshot/scala/testing.html#Synchronous_Unit_Testing_with_TestActorRef
Documentation there is pretty good.
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.
I'm a real Erlang newbie (started 1 week ago), and I'm trying to learn this language by creating a small but efficient chat server. (When I say efficient I mean I have 5 servers used to stress test this with hundreds of thousands connected client - A million would be great !)
I have find some tutorials doing so, the only thing is, that every tutorial i found, are IRC like. If one user send a message, all user except sender will receive it.
I would like to change that a bit, and use one-to-one discussion.
What would be the most effective client pool for searching a connected user ?
I thought about registering the process, because it seems to do everything I need, but I really don't think this is the better way to do it. (Or most pretty way to do it anyway).
Does anyone would have any suggestions doing this ?
EDIT :
Every connected client is affected to an ID.
When the user is connected, it first send a login command to give it's id.
When an user wants to send a message to another one the message looks like this
[ID-NUMBER][Message] %% ID-NUMBER IS A FIXED LENGTH
When I ask for "the most effective client pool", I'm actually looking for the fastest way to retrieve/add/delete one client on the connected client list which could potentially be large (hundred of thousands -- maybe millions)
EDIT 2 :
For answering some questions :
I'm using Raw Socket (Using telnet right now to communicate with server) - will probably move to ssl later...
It is my own protocol
Every Client is a spawned Pid
Every Client's Pid is linked to it's own monitor (mostly for debugging reason - The client if disconnected should reconnect by it's own starting auth from scratch)
I have read a couple a book before starting coding, So I do not master yet every aspect of Erlang but I'm not unaware of it, I will read more about it when needed I guess.
What I'm really looking for is the best way to store and search thoses PIDs to send message directly from process to process.
Should I write my own search Client function using lists ?
or should I use ets ?
Or even use register/2 unregister/1 and whereis/1 to maintain my client list, using it's unique id as atom, it seems to be the simplest way to do so, I really don't know if it is efficient, but I'm pretty sure this is the ugly solution ;-) ?
I'm doing something similar to your chat program using gproc as a pubsub (similar to the demo on that page). Each client registers as it's id. To find a particular client, you do a lookup on that client id. To subscribe to a client, you add a property to that process of the client id being subscribed to. To publish, you call gproc:send(ClientId,Message). This covers your use case, the more general room based chat as well, and can handle distributed masterless registry of processes.
I haven't tested to see if it scales to millions, but it uses ets to do the storage and gproc is rock solid code by Ulf Wiger. I wouldn't count on being able to write a better implementation.
I'm also kind of new to Erlang (a couple of months), so I hope this can put you in the correct path :)
First of all, since you're a "newbie", you should know about these sites:
Erlang Official Documentation:
Most common modules are in the stdlib application, so start from there.
Alternative Documentation:
There's a real time search engine, so it is really good when searching
for specific modules.
Erlang Programming Rules:
For you to enter in the mindset of erlang programming.
Learn You Some Erlang Book:
A must read for everyone starting with Erlang. It's really comprehensive
and fun to read!
Trapexit.org:
Forum and cookbooks, to search for common problems faced by programmers.
Well, thinking about a non persistent database, I would suggest the sets or gb_sets modules (documentation here).
If you want persistence, you should try dets (see documentation above), but I can't state anything about efficiency, so you should research this topic a bit further.
In the book Learn You Some Erlang there is a chapter on data structures that says that sets are better for read intensive systems, while gb_sets is more appropriate for a balanced usage.
Now, Messaging systems are what everyone wants to do when they come to Erlang because the two naturally blend. However, there are a number of things to look into before one continues. Messaging basically involves the following things: User Registration, User Authentication, Sessions Management,Logging, Message Switching/routing e.t.c. Now, to do all or most of these, one needs to have a Database, certainly IN-MEMORY, thats leads me to either Mnesia or ETS Tables. Since you are new to Erlang, i suppose you have not yet really mastered working with these. At one moment, you will need to maintain Who is communicating with who, Who is available for Chat e.t.c. Hence you might need to look up things and write things some where.Another thing is you have not told us the Client. Is it going to be a Web Client (HTTP), is it an entirely new protocol you are implementing over raw Sockets ? Which ever way, you will need to master something called: Concurrency in Erlang. If a user connects and is assigned an ID, if your design is A process Per User, then you will have to save the Pids of these Processes or register them against some criteria, yet again monitor them if they die e.t.c. Which brings me to OTP and Supervision trees. There is quite alot, however, tell us more about the Client and Server interaction, the Network Communication you need e.t.c. Or is it just a simple Erlang RPC project you are doing for your own revision ?
EDIT Use ETS Tables, or use Mnesia RAM tables. Do not think of registering these Pids or Storing them in a list, Array or set. Look at this solution which was given to this question
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.
I am trying to create a pipe to use between two processes to send information. The two process are not related and implementation with signals has a problem where if the process that recieves the signal is doing a sys command it intreprets the signal as an intrupt.
I am new to perl so any help trying to have two processes use pipes would be really great!!
The perl man page perlipc talks a bit about using named pipes.
You didn't mention any specifics as to your project, so this may be completely off of what you are trying to achieve but have you considered implementing sockets as your IPC mechanism? Again, I understand this may not make sense in the context of your particular project but it may allow you to create a process with the ability to communicate across a network instead of just one machine.